I will start with truism, using the sentence that many companies, regardless of the industry, work similarly based on a specific organizational structure, which results in the subordination and definition of tasks, duties and rights. At the head of the organizational unit is the manager, the director (but not the leader). Watching each organization chart with attached rules we get the impression that everything is in the best order. But this is only an impression, because despite this proven (and archaic) management method, the company has problems to achieve a higher level of competitiveness, financial turnover, stock quotes, customer service standards and therefore is considering the implementation of a new or more modern business decision support system.
Principle I – define business processes
Before we implement the IT system, it is necessary (if there are none) to develop and implement business processes. It is not an easy task, but it can be simple. The condition is having experience, knowledge and (I say with all my strength) giving this task the rank of a project. Someone who implemented the system where processes were developed and implemented does not know how many problems will occur each day when implementing the system in a company without developed business processes, even if there is a specification of needs. But it concerns an IT system whose task is to facilitate the automation of work. When asked what job – usually I hear – “… work, he orders, and I sell, I issue an invoice based on his WZ document …”. But you have to find out who has the authority, who can approve who the document goes to, when the next stage of work begins – these are the individual steps in the system. It is therefore worth having the processes described, because it will simply reduce the costs, implementation time
and (above all) the risk of failure.
Principle II – processes must function
Same needs are not everything. And in this place, I would like to warn you not to start implementing new IT tools without prepared, analyzed and implemented business processes. The success of the system implementation does not depend on the final stage of the project closure, but on whether the orderer has received what will measurably affect his financial, marketing or organizational condition. Receiving and acknowledging the last stage of implementation is definitely a successful supplier, but not necessarily a successful contracting company.
Principle III – violation of the status quo – can be painful
You should approach flexibly with every conceivable business process. Elastically – that’s because it is not always possible to start work on comprehensive development of processes, even the attention to the resistance of workers’ teams. It is worth taking care of the advertising of these activities, showing the strengths and weaknesses, and above all justifying the changes.
Propaganda actions should be carried out very carefully, so that “unnecessary” wording does not cause a storm of dissatisfaction. We should remember that employees (especially those with extensive seniority) will be very sensitive to their own interests in the company. In addition, each employee will refer all information to his / her range of responsibilities. It is worth to take care of project marketing by building competences of each of the implementation participants. In addition, a flexible and cautious approach will allow the project to be phased.
Rule IV – we describe the existing state (even if it is a mess)
The description of the processes must be subjected to iteration. The initial diagram is to be used to analyze and look for simplifications. This approach will allow us to formulate real requirements in relation to the new IT system. Thanks to this, it will be easier for us to develop a map and a model of processes (the map shows the relationships between elements of the process or processes, and the model – shows the functionality of the process).
Rule – use simple notations
How important is the adoption of a good modeling tool, probably everyone who has met with the processes. In the past I used UML notation and I was a big supporter of this tool. I also used a method of drawing process elements using graphic programs, simple – (seemingly) intelligible, but in cases of complex processes, it became labor-intensive and risky due to misunderstandings (although initially all the definitions of objects were clear and understandable).
Currently, I usually use BPMN, an easy and precise tool. In addition, BPMN has Polish certification (IBS PAN). Business Process Model and Notation is a graphical notation developed over 13 years ago and systematically updated. You can easily describe individual logic of business processes. (example use of BPMN notation – https://www.youtube.com/watch?v=JDY2EtmV26g).
Principle VI – start a project with a catalog of implemented business processes
The process catalog gives us the prospect of successful implementation, the success of the implementation recipient. Customers ask if it is possible and whether it is beneficial to consider implementing a preconfigured system, such – commonly known as – “out of the box”. I usually reply that yes, but only if I have a small amount of data. For large databases, solutions designed for this should always be used.