10 Rules for Business Intelligence
Introduction
I worked for 1.5 years in a large large company that is engaged in wholesale and retail supply of oil and gas equipment (turnover of about 30cc rubles). Inside, a management system (developed on 1C) was introduced, including several configurations for several bookkeeping, warehouses, etc. About 2k users working in the system daily.
The team of analysts supports and develops the entire system. During this time, we have developed rules that, in my opinion, will help all analysts (business, requirements) and managers, support staff, and even a little developers in a large enterprise segment.
1. Feet analytics feed
This rule was invented by my colleague. If you are in the same building with users and key customers, then you need to visit them and talk with them. Since not everyone knows how to clearly and clearly express their thoughts in writing, sometimes one 15-minute conversation can replace a three-day correspondence.
Ignoring this rule will lead to long mail correspondence and endless formalization of tasks.
2. Draw
Drawing business process diagrams and interface sketches will allow you to understand the task and easily explain your vision to the user. Beautiful flowcharts of business processes make a huge impression on the customer’s leadership. Personally, I used the EPC notation with free add-ons (simple enough to understand and clear enough).
Ignoring this rule
3. Simplify (or don't complicate)
Analysts and business analysts tend to complicate tasks more often than we would like. Regularly this negatively affects the result. I believe that solving problems should be as simple as possible.
After about a year of work, I realized that you need to think according to the following algorithm:
a) we will come up with a simple solution;
b) try to find out why it does not fit;
c) we complicate a little;
d) trying to find out why it does not fit;
e) we complicate a little;
etc. until the solution is optimal.
Ignoring this rule will lead to the creation of bicycles and unreasonably complex decisions that no one will use.
4. Interview all future users and all participants in the process
The vision is subjective, so try to find out the opinions of everyone who is concerned with the future revision, even those who will be affected adjacent. In practice, there is always an active user who bends his line, but it may turn out to be wrong, since he does not know all the pitfalls and activities of other departments as well as his own.
Ignoring this rule will lead to the fact that the solution will not suit everyone, but will satisfy only one user with whom you work.
5. Get to the bottom of the problem
Users constantly ask for some buttons on the forms, some filters on the lists and do not like to explain why. But after finding out the answer to the question “Why?” You can come up with a completely different solution that may work better and more efficiently.
Ignoring this rule will result in the solution being incomplete or not meeting all the requirements of the task.
6. Solve global challenges
For example, you are asked to make a document to include a department in the process of working in your ERP system. Based on this requirement, you should set the global task “Automation of the Planning and Economic Department” and find out related requirements, but also get to the bottom of the rule 5. This will help you immediately develop a solution that will cause fewer improvements in the future.
Ignoring this rule will lead to the fact that tasks will not be solved.
7. The user is aimed at success (result)
It is a very common misconception that a user or customer does not understand what they need and have little interest in the result. The myth emerged from the fact that they regularly savor the little things and there they drag out development. In fact, all users and customers want results. Do not forget about it!
Ignoring this rule will lead to conflicts.
8. Make universal decisions (do not automate automated)
A huge number of activities are automated. There are quite universal solutions for trading, task management, accounting, etc. But each subsequent customer believes that it is his company that does not work like everyone else and processes are not like everyone else. Sometimes this is true, but in most cases, easily changing the processes to the classical ones will save the client a lot of money, and you will have a lot of nerves.
Ignoring this rule will lead to unnecessary expenditure of resources.
9. The contractor must understand what he is doing.
Analysts are regularly lazy to explain the essence of the problem to developers, and those who are too lazy to listen and delve into. It is necessary for the developer to understand what he is doing and why, and not just "add a button that ...". This will allow the developer to make an informed decision, and sometimes give wise advice to the analyst.
Ignoring this rule will lead to poor design decisions.
10. Avoid ambiguity
Break the task down to such details that the vision of the result is unique for you, for key users and for developers. This is not always possible, but striving for this is necessary.
Ignoring this rule will lead to solutions that do not meet the tasks.
Recommended reading:
1. " Development of software requirements ", 2004. Carl Wigers
2. " Principles of working with software requirements. A unified approach ", Dean Leffingwell, Don Widrig