Business Modeling in IT Development
In this article, we will discuss some important aspects of business analysis in terms of describing automated processes, their optimization and reengineering for the purpose of subsequent digitalization and the expected usefulness of such modeling for business.
The essence of the work of a business and systems analyst is to document the life cycle of IT solutions, from the concept stage and collection of requirements through design to implementation, including the technical working project. Analysis artifacts, including the business model, are the results of such documentation. According to GOST 34.601-90, there are eight main stages of creating an automated information system (AIS), the first five of which are within the competence of analysts (see table).
Business analysis for the purposes of developing an AIS in the most general and brief presentation looks like this:
we collect information about how the customer’s business or a typical buyer in the industry market is structured, what is good about it and what is not, what is missing;
we formulate business rules as instructions (must) and restrictions (must not) of business processes at the proposed automation object or in the buyer’s organization;
we describe user stories as the expectations of stakeholders and key users from the capabilities of the AIS;
we compile a list of business processes within the project boundaries (scope);
based on business rules, we draw business process diagrams – diagrams with work sequences in a convenient notation, for example, BPMN, IDEF0, ARIS EPC, this is an “as-is” model;
based on business rules and user stories, taking into account the criteria and limitations of optimization, we draw a model of business processes “how it should become (to-be)” in the same notation – we do reengineering;
We conduct a GAP analysis and evaluate the expected effects of reengineering.
Voila, we have formed a business model! Let's dwell on the last three points in more detail.
Process diagrams
To draw processes, different standards are used – so-called notations or methods.
One of the most popular is BPMN (https://www.omg.org/bpmn). It is essentially somewhere at the intersection of the capabilities of SADT, IDEF and UML sequence diagrams and is therefore most useful for preparing business process workflows, functional models for automated processes, and for designing system integrations.
UML Language (https://www.omg.org/spec/UML) – this is almost 800 pages of engineering wisdom, draw as much as you want! In fact, diagrams are more often in demand:
classes – for organizational structures, subject area ontologies, logical data schemes;
precedents – for use cases, business rules and user stories;
sequences – for data flow diagrams between modules and components of the system, as well as with the external environment.
IDEF Family (https://www.idef.comin RuNet – via VPN) – a group of methods, including, among other things:
IDEF0 – for business models where it is important to reflect not only incoming signals (including initiating ones) and results, but also resources, tools, control agents and regulations;
IDEF1X – for relational logical and physical data schemas of the entity-relationship type;
IDEF3 – for status models of data objects and information flow models, illustrates use cases and is useful in setting up the development of functional requirements.
Of course, this is not an exhaustive list, and you will probably encounter non-trivial tasks where other notations will help, however, I will never tire of repeating that the main thing is not the form of the artifact, but its content and, therefore, its usefulness for the project.
From experience, I can offer several tips for circuit design in IT:
a diagram should be better than any text that could describe its contents if the diagram can be used more easily and quickly to explain in words what it is for;
Cut out the inscriptions and objects on the diagram in at least three iterations:
Occam's razor – “diversity should not be assumed without necessity”;
throwing out all words and elements that are unnecessary for the context;
inversion check: mentally replace the inscription with the opposite in meaning – if it turns out to be nonsense, both in the absolute and in relation to the subject of modeling, most likely, you wrote something useless: for example, “the News section contains the current agenda”, but does the news write about the dust of time;
the diagram should show the necessary but sufficient level of detail, it is pointless to try to answer the eternal questions of existence in one picture, in the end it will turn out worse than “42” from The Hitchhiker's Guide to the Galaxy, display no more than seven entities on one level, remove secondary details from the model.
Optimization and reengineering
When talking about automation or informatization, the full cycle of design work often by default assumes reengineering – analysis and development of such recommendations for restructuring business processes that, at a minimum, will allow this automation to be implemented. In fact, reengineering is not always required for this, and they are different things from the AIS implementation project in the general sense. You can redesign processes without additional automation, you can do it together, and sometimes everything is fine with the business anyway, it is enough to adjust only some parameters with the help of IT, and not its entire scheme.
Reengineering needs meanings – why are we changing and where are we going. They are called criteria (measure) of optimization – efficiency is managed through resource intensity, efficiency and effectiveness of processes (triangle). And, by the nature of any system, there are certain limits – optimization restrictions, a corridor of possibilities, above and below the threshold values of which we cannot go in the process of changing the criteria. To do reengineering, it is necessary to define the criteria and limitations of the planned optimization. If the process is not too difficult to at least approximately describe using a function, mathematical methods will be very useful to you.
Since reengineering is about finding the optimal, it is important to understand that it is always dichotomous, the function has two extremes, above and below zero. Only one of them will become an “improvement” in a specific case, it is necessary to find out in advance which one. It is no less critical to maintain focus on alternative costs – potential opportunities that are inevitably missed with each step of management when choosing optimization parameters: this is the price of change. Given the limitations, it is fundamentally impossible to grow infinitely across the entire field of the efficiency triangle.
Hence, business process optimization is more about balancing resource allocation and implementing changes without deterioration, according to the Pareto efficiency principle: “Any change that does not cause losses to anyone and benefits some people is an improvement.” I foresee objections – you can’t please everyone, so you can slide into endless compromises to degenerate non-interference, and critics of the neoclassical school of economic theory will agree with this. At the same time, the modern extended interpretation of the Pareto optimum – the compensation principle – allows for local “deteriorations” if reengineering as a whole brings enough benefit to justify them, so look for your own balance.
How can we understand, based on the business model, that a specific process needs optimization? Let's look at the as-is diagram (using the BPMN notation as an example) using a simple test:
in the diagram of one business process, the number of participants (roles – paths) is similar to or exceeds the number of steps (works);
in at least one exclusive OR operator, more than one output stream leads directly to the exit of the process;
there are no notifications to key process roles about changes in the status of work;
more than 2 complex conditional statements in one process;
more than 2 escalations in one process;
at least one AND operator has more than 3 incoming control flows (not the default);
there are more than 3 final exit events in one process.
If you answered “yes” to more than 3 points out of 7, your scheme (well, and the process) should be optimized – first try to eliminate the corresponding shortcomings. For example, point 1) – indicates a blurring of responsibility, excessive dependence of results on the human factor and low efficiency, which means you can work on reducing the number of roles involved.
An important point: when choosing optimization options, I advise maintaining a balance of three factors:
the price of choice (not only in money);
the influence of choices within and outside the process;
your personal attitude (expertise).
Conclusions: Benefits for Business
As we have seen, a business model describes existing schemes and rules for performing certain work processes, and may also include recommendations for changing them. What does this give?
First and foremost, modeling helps to see what is happening as a system – to take in all participants, their work and interrelations at once. Such a systemic vision is necessary for stakeholders to self-assess, understand their place and differentiate the business as a whole from competitors, and to form a development strategy.
Secondly, when you draw business process diagrams, regardless of the volume of source data and the depth of immersion in the context, new, previously undiscovered questions and nuances are sure to emerge, especially in terms of logic and expediency. The more detailed the model, the more hidden opportunities for improvement it will reveal – it is useful to note them in the comments directly on the diagrams.
Thirdly, if, at the request of interested parties or during the analysis, it turns out that reengineering is necessary, the model will suggest optimization criteria – those quantitative and qualitative characteristics that determine the assessment of the results of business processes, what exactly and in what direction needs to be changed. Moreover, the limitations of such changes can also become clearer thanks to visualization.
If we look at business modeling not as a sequence of actions, but from the point of view of its essence, two things are important above all:
WHAT the system does (object, module, application, complex, solution, etc.);
HOW the system does something.
Moreover, we can use another invaluable method of science – induction – and say: everything we can learn in principle by analyzing the subject area, the automation object, its business processes, possible ways of their optimization, digitalization tools, implementation effects, etc. – it’s all about WHAT and HOW. This is the nature of knowledge. Therefore, analysis is useless without studying the dynamics: with the help of a business model, we consider objects and systems in action, in all four dimensions of space-time. The model describes not just a process – a regular flow of work, repeated with a certain periodicity, each iteration can differ in its own features – for example, speed, costs, results. Studying these fluctuations, we see the analyzed in the full scope of its complexity and interrelations with the outside world.
