Transcription
We can start our open lesson today. It will be dedicated to the basics of BPMN for beginners. So, let's begin our introduction and start our lecture.
First of all, let's check the connection. Please write a plus in the chat if you can see and hear me. If you can't see or hear me, please let me know. I'll give you a minute or two to see your responses.
I see the pluses; everything is good. I should also mention that there is a slight delay on my end, meaning I ask a question, and it will likely take a couple of seconds before I see your answer, even if you respond immediately. So, I will sometimes pause to give you a chance to respond or ask questions.
Since I started talking about pauses, let's smoothly transition to the rules of our webinar. The webinar is meant to be interactive, meaning I will ask questions and expect your answers. There is no need to be afraid; this is not an exam, just a dialogue. We will discuss various interesting artifacts that we encounter during the lecture. If something is unclear, feel free to ask questions in the chat during the lecture.
I will respond to them not immediately but after each logical block. You will see a slide that says "Are there any questions?" This is the time allocated for your questions. If you haven't asked them during the lecture, you can do so then.
I apologize for the repetition, but I want to clarify that I see the questions in the chat, but I will respond during the designated time. Also, based on my experience from previous open lessons, there are questions that do not have short answers. I will leave those for the end of the lecture. If there is a broad topic, we will discuss it after the lecture, once our allocated time is over.
Unfortunately, I do not work according to GOST standards, or perhaps it's a good thing. Therefore, if you have questions related to GOST or the application of BPMN in government structures, I won't be able to answer them. I haven't lived in the Russian Federation for quite some time, so I don't know how processes are structured in government organizations. However, I can likely answer questions related to commercial organizations, as they are more or less similar in the country where I currently reside.
Now that we've covered the rules of the webinar, let's move on to introductions. While I introduce myself, I would like you to write in the chat your name, where you work, whether you are in IT, or if this is your first lecture on how to enter the IT field. You can also share your main goal for attending this session.
I will read your responses after I introduce myself. My name is Maria, and I have been working as an analyst for the past 13 years, specifically as a systems and data analyst. I am more focused on development than on business.
Before becoming an analyst, I worked in technical support and briefly as a technical writer for about four years. That's all you need to know about me. My main areas of expertise are banking and healthcare, specifically in the development of medical devices, and I have also worked a bit in clinical research.
I will give you a minute or two to introduce yourselves in the chat. Please share your name, your experience in IT, and where you are joining us from, as well as your main goal for attending this lecture.
"I want to understand BPMN," writes Alexander. We will try to achieve that today. I will explain how we will approach BPMN later.
I am also interested in your experience in IT because it helps me gauge how deeply we should dive into the topic. For example, should I explain what requirements are? From the comments I see in the chat, it seems that there is some experience in analytics, so we can skip some details, like explaining what a requirement is. This will simplify the material presentation.
However, if you haven't introduced yourself and you don't understand some terminology, please write in the chat, and we will clarify it. I see that Herman has zero experience, so I will explain some terminology as we go along.
For experienced analysts with knowledge of BPMN, this lecture will still be useful, but it will be more introductory, focusing on why BPMN is necessary and the notation itself.
Let's gather feedback and make the lecture more in-depth regarding the application of the notation to ensure everything is clear.
Andrei mentions he wants to understand the difference between data analysts and systems analysts. We probably won't cover that in this lecture.
Okay, I see we have both experienced colleagues and those without experience. Let's take a closer look at some points, such as what a requirement is and how to work with it.
Thank you all for your responses. Now, let's move on to the next slide, which outlines the route of our webinar.
We started with introductions, which we've completed. Next, we will look at what Otus is and what it offers, who teaches at Otus, how we teach, what a process is, and how to visualize it.
We will discuss what the notation describes, specifically BPMN, what elements are in BPMN, how they are used, and then we will try to look at a real, or at least a realistic, business case to see how a business process can be written using a BPMN diagram.
After that, we will introduce the course team, provide information about the course, and leave some time for reflection. I hope the route of the webinar is clear.
Now, let's move on to our first section about Otus: who we are and how we teach.
Otus specializes in IT education, and our unique feature is advanced programs for experienced specialists and the quick launch of courses on new technologies. We have an educational license, so you can receive a certificate of higher qualification or a diploma of professional retraining, as well as make a tax deduction.
Now, a bit about the course directions: we have programming, infrastructure, testing, and analytics. Analytics is divided into system analytics, business analytics, and data analytics. We also cover various management systems and information security.
Moving on to the numbers, we have over 130 courses for junior and mid-level specialists, more than 600 instructors sharing relevant knowledge and real cases in demand in the IT industry.
Regarding our instructors, all of them are active professionals. Our main activity involves participation in live projects, and our knowledge is naturally aligned with current realities. Our programs are constantly updated based on what we encounter at work, and we strive to keep up with the times.
Since the company's founding six years ago, over 20,000 graduates have completed training in programs tailored to the requests of leading employers, and more than 430,000 specialists in our community read our materials, learn, and communicate on our platforms.
Training at Otus is structured as follows: let's save the details for later. Now, let's move directly to what BPMN is.
We will start with the question: why visualize processes? But before we get to that, let's clarify what a process is. I invite you to describe your definition of a process within an organization in the chat.
If you have any preliminary guesses about why it should be visualized, feel free to write those as well. I'll give you two minutes. Remember, there are no wrong answers; everyone likely knows something about this.
I see the following responses: "working on something according to regulations," "visualizing for perception," "a schematic representation of activities divided by roles," "a list of actions to move from point A to point B," "visualizing to analyze or standardize the sequence of actions," "a set of actions."
All of you are correct! A process is a list of actions within an organization or between two organizations that allows us to move from point A to point B.
For example, in our business case for simplicity, we will consider a scenario where there is interaction between two organizations. A supplier or client wants to make a purchase, sends a request to the organization from which they want to buy a product, and certain actions occur within the organization. As a result, the product is shipped to the client, who is satisfied.
This is a high-level overview, but it doesn't describe everything that happens at each stage. Therefore, we need to delve deeper into each of the larger high-level stages, breaking them down into smaller steps.
This is where BPMN or any other diagram comes in handy to determine what stages exist within each segment of the process, how these stages are interconnected, how quickly they are executed, and whether there are any problems. If problems occur, we need to understand how they are addressed.
Based on this description, we determine what artifacts we produce, where we send them, in what form, and whether this happens once or multiple times. Essentially, we take a larger process, break it down into smaller processes, and describe in detail how everything happens within those smaller processes.
This is why we need BPMN, to put it simply.
Now, are there any questions about this section? Perhaps there is some terminology that you haven't encountered before? I'll give you a couple of minutes to write in the chat, and I will answer your questions.
If there are no questions, please write a minus. I hope this slide or the one above is clear.
Great, I see no questions, so let's move on to the next section.
The basics of BPMN: we visualize processes. It's important to note that processes in organizations can vary, and therefore, different diagrams, schemes, and notations are applied to describe processes.
We have diagrams that describe organizational structures, functional diagrams that describe functions within systems, and informational diagrams or component diagrams, among others. These diagrams describe the basis of how something occurs or what components a particular software consists of.
BPMN falls into the category of diagrams that describe processes within an organization and explain how everything happens, how departments and employees interact within the organization.
This is a high-level diagram, but I will explain more about it later.
Are there any questions at this stage? If not, please write a minus, and I will move on to the next slide.
Okay, I see the minuses, so let's proceed.
Who are the consumers of our diagrams? Naturally, we don't create diagrams just for the analysts who work with them; we need to show them to someone who will understand them.
Let's look at who might be interested in our diagrams besides analysts. From my personal experience, the main consumers from this list are top management, financiers, economists, and managers.
BPMN diagrams are primarily business diagrams. In practice, top management is often the first person or stakeholder who significantly influences the process. They are the primary consumers of BPMN diagrams alongside analysts.
Why? Because we meet with them first when we need to gather business requirements. We need to understand how the business operates and how they want our software to fit into their organization. We quickly capture this using BPMN diagrams.
At this level, the BPMN diagram is usually quite simple and describes only high-level processes within the organization. It is not oriented towards technical specialists and therefore looks quite straightforward.
Next, we have financiers, economists, and sometimes managers. Here, we add information about transactions, how payments move between different parts of the business. For managers, we can include descriptions of interactions with subordinates or neighboring departments.
At this level, our BPMN diagram becomes more complex. Then we have technologists and executors, and sometimes automation is added. At this point, the BPMN diagram also accumulates additional technological details, such as elements representing databases and tasks performed not by our process participants but by the system itself.
Thus, the BPMN diagram at this level will be the most complex and possibly difficult for someone who has never encountered a BPMN diagram before to understand.
It's important to understand that we work from top to bottom. The analyst first discusses the diagram with top management, then with financiers, economists, and managers of departments, and finally with technologists, executors, and IT specialists.
It's worth noting that this doesn't mean that there is always just one diagram. Most likely, at the top level, you will create a diagram with, say, five elements, and then each element that implies a process will gradually be decomposed into smaller diagrams until you have a detailed diagram for just one element from the top-level diagram.
I understand that this explanation may be somewhat confusing, so let's clarify it with a practical example.
Suppose we met with top management, and they said they want the client to place an order, which the manager will accept and enter into the system. The system will process it and return a response to the client.
We will have a very simple diagram consisting of three tasks: accept the request, process the request, and return the response.
If we take this diagram and discuss it with economists and managers, we might find that when we accept the request, two people need to process it. For example, a manager enters the request into the system, and then the system processes it. Additionally, there might be a marketer or economist who checks whether we can fulfill the request.
So, the part responsible for accepting the request breaks down into three parts: entering the request into the system, processing the request with the help of the economist, and making a decision.
When we pass this more complex diagram to technologists, executors, and IT specialists, they will further process it and explain that to enter it into the system, we need to add a task to save it in the database, update some tables, and so on.
Thus, the diagram gradually becomes more detailed from top to bottom.
I'll pause here and ask if there are any questions at this stage.
While I wait for your questions, I see that Alexander asked if the colors were chosen randomly. Yes, they were chosen randomly and are not significant.
I'll give you a couple of minutes to see if you have any questions.
Elena, at the end of the lecture, I will provide a brief list of tools, and there will be a link to BPMN.
Dmitry, the lecture will last for an hour and a half.
Okay, let's move on to the next question: how deeply should we dive into the topic? I've already partially covered this.
We have a high-level overview where we describe general business processes within the enterprise. Then we move to the management level of activities and departments, and finally to the level of departments and detailed processes.
If necessary, we can go down to the level of workplaces, employee activities, and transaction descriptions within the enterprise.
In my experience, BPMN is most often applied from level one to level four. However, if there is a desire within the company or team to create more detailed diagrams, it is possible to cover levels four to eight.
BPMN also operates on different levels. There is an analytical level that uses a limited set of symbols, aimed at documenting actions. The audience here is business, and compliance with standards is conditional, meaning strict adherence to notation as described in documentation is not mandatory. The complexity is moderate, so anyone looking at this diagram can understand it.
Next, we have the descriptive level, which is slightly lower and is for those working within the company, more for technical personnel. A full set of symbols is used here, and the goal is to document events and exceptions, covering all possible flows within the business process.
If you've heard of "Happy Path" and "Not Happy Path," this refers to error handling and so on. The audience here includes both business and IT, serving as a bridge between the two. Compliance with standards is quite strict because deviations are expected at this stage, as people still work with BPMN diagrams. The complexity is high.
Finally, we have the executable level, which is usually for automation. At this level, the diagram is viewed not only by people but possibly also by some software code. A full set of symbols is used, and the execution of processes means everything will be executed exactly as described in the diagram.
Therefore, we need to be very careful. Compliance with standards is strict, and such diagrams at the executable level are often written for automation. We cannot explain to a machine that it should think for itself at a certain moment; it will execute exactly as described in the diagram.
Thus, the executable level must strictly adhere to the notation and may be difficult for an unprepared person to understand.
In my practice, I mostly encounter the analytical and descriptive levels. I try to stick to them because the executable level is more of an architect's work. However, it's important to know about it.
Are there any questions about the levels of BPMN application?
If you can't see me, please let me know how long you've been working with BPMN.
I have been working with BPMN for eight years and have been in analytics for about ten years.
I hope I see the minuses, which means we have a basic understanding of why we draw diagrams.
Let's go over the levels again. When we talk to a business, we have a client who may not be connected to IT. For example, a worker from a manufacturing company comes to us wanting to automate something in their production.
To understand how everything is organized in their production, we talk to them and describe this analytical level through BPMN.
At this level, we will outline where their materials come from, how long it takes to process them, what the output is, and so on.
This is a very high-level overview of how their business operates.
The descriptive level is when we take this high-level diagram and describe in more detail what happens at each stage. This is for both business and IT because developers need to understand how to automate certain processes within the business.
For example, if we describe the task of receiving goods at the high level, we will detail that when receiving goods, we need to enter all the goods into the database through an interface.
Our diagram must confirm the accuracy of the data, which will be at the descriptive level.
At the executable level, we will add the technology stack used when entering goods into the database, and so on.
This is a very detailed level where we describe not only what needs to be done but also how it should be done.
The level of detail should be determined by reasonable sufficiency. However, I advise against making diagrams too large with very detailed processes, as they can be quite difficult to read.
From personal experience, I recommend that in one diagram, there should be no more than ten to twenty tasks. If your diagram grows larger, it is likely that you need to break down some of the described processes into subprocesses and provide links from one main process to another, allowing for easy navigation between diagrams.
I hope everything is clear.
I will give you a couple of minutes to see if any questions arise.
If there are no questions, let's move on to the most interesting part: what the notation looks like.
This is still not the notation; these are the elements of the notation, which I will explain in more detail after this slide.
The elements are divided into four categories. The first and most important are flow elements, which describe the process.
The BPMN diagram is read either from left to right or from top to bottom, meaning we must arrange elements either left to right or top to bottom.
These are mutually exclusive; it doesn't mean the diagram is read diagonally.
Flow elements include events, which are elements that initiate certain behaviors of users or tokens. Events can be start events or end events, represented by empty circles.
Inside, there may be a pictogram, which I will show you later. Depending on this pictogram, the meaning of the event changes.
Next, we have activities, which describe the business process or a stage within the business process.
Then we have gateways, which split and merge flows. A person reading the diagram from left to right will understand which flow to follow based on the type of gateway used and how it is labeled, depending on the situation.
Next, we have connecting elements, which are the main arrows that help us understand the order in which flow elements proceed.
Often, the order is not linear, and there may be switches between areas of responsibility, which I will explain later.
Next, we have message flows, which describe how information is transmitted using dashed lines. These lines can go in any direction—right, left, up, down—and simply indicate that certain flow elements are sending messages to each other with some information.
When I say "message," I mean the transmission of information; it doesn't necessarily mean there will be a letter or a call. For example, if we describe two databases where information is copied from one to another, that is also a message flow.
Associations show how certain elements are interconnected. Annotations or data objects can also be displayed through associations.
Now, regarding responsibilities: some users or specialists who use BPMN diagrams do not like pools and lanes and believe they can be omitted. This is not a violation of the notation; you can choose to use them or not. I personally use them because they help me better identify the participants in the process.
In a BPMN diagram, pools represent different organizations, while lanes represent participants within one organization.
For example, if we want to show how the company "Horns and Hooves" interacts with the tax office, we will have two pools: one labeled "Horns and Hooves" and the other "Tax Office." They will not be connected; they will be two separate pools.
Within our company, we may have two employees: an accountant and an economist. The accountant and economist will be separate lanes within our "Horns and Hooves" pool because they are both employees of the same organization.
Communication will occur between the accountant within "Horns and Hooves" and the separate pool representing the tax office.
Artifacts are auxiliary elements that help make the diagram easier to read. We can indicate that an element represents a data object, such as a database or a system task.
We group elements to define subprocesses, and annotations are simply additional notes that can contain any text, not defined by the notation.
Are there any questions about the elements? If you have any, please ask. If not, please write a minus, and I will move on to the next slide.
Okay, I see no questions for now. If any arise, I will definitely return to them.
Let's move on to a more detailed explanation.
I have already covered the participants. We have pools and lanes, which can be referred to as lanes depending on the translation. They can be located within a pool or lane.
Artifacts are text annotations, and we group elements when we want to display a subprocess.
Exclusive gateways indicate that further actions can occur only according to one of the scenarios. Inclusive gateways indicate that actions can occur according to one or more scenarios.
Parallel gateways indicate that actions can occur simultaneously, depending on how many flows exit the gateway.
For example, if we have a secretary, a parallel gateway can explain that the secretary can simultaneously answer a phone call and respond to an email.
If we use an exclusive gateway, the secretary can either talk on the phone or type something on the computer.
If we use an inclusive gateway, the secretary can do both simultaneously, depending on her mood.
If we talk about moods, we have event gateways, where our actions depend on what event occurred.
For instance, if the secretary is sitting at her desk, we need to determine whether she will respond to an email or answer the phone.
If we have an event gateway, we can specify that if the phone rings, we follow that flow. If an email notification arrives, we follow the flow for responding to the email.
So, everything depends on the event.
Alexey asks if a lane can have more than two lines. Yes, there are no restrictions on the number of lines.
Dmitry mentions that the first gateway is used as a fork with an alternative scenario. Yes, that's correct; this is an exclusive gateway, and after this gateway, the token can only follow one of the flows.
We will look at examples later.
Now, let's move on to the next slide.
Data can be an object, meaning any XML or similar data. A data store refers to a database, which we can also indicate in our diagram.
A task is the simplest activity, such as receiving goods or responding to an email. A subprocess indicates that there is no process currently described, but it implies that receiving an email may involve several steps, such as turning on the computer, opening the email client, clicking on the email title, and reading it.
We don't want to describe all of this in one diagram, so we create a task called "Receiving Email," which implies a more extensive process that can be read in another diagram.
The plus sign indicates that there is something more significant behind this simple action of receiving an email, which can be read in another document.
We will discuss how to describe subprocesses later.
In general, processes can be of three types. Sometimes we start describing our diagram and include a subprocess within the same diagram. If this activity repeats, we do not describe it again but provide a link to the same diagram.
Sometimes a subprocess is described separately at the bottom, and we link to it.
Other times, a subprocess is not described in our diagram at all but is documented elsewhere, and we simply note that it exists.
Now, what influences the course of the process? Events.
There are ten types of events, but I probably don't use all of them in my practice.
The first event is abstract, which can also be intermediate. It usually indicates how our process starts and ends.
Message events refer to the transmission of information. Timer events indicate that we are waiting for something.
Escalation events indicate that we are escalating to a higher level or addressing an issue.
Compensation events refer to returning to a previous point. Signal events indicate that a certain stage of the process has ended, triggering the start of another stage.
Composite events indicate that something is happening in parallel within our diagram.
If you have any questions about these events, please write them down. If not, please write a minus.
Yes, that's correct; a signal is more of a trigger, while a message is information we transmit.
I will be honest; in my daily practice, I use abstract messages, timers, escalations, and conditions. I rarely use signals.
Is it possible to associate any of the events with an emergency exit? Most often, in my practice, we describe processes with positive event flows.
If an error occurs, we can provide an example of compensation. I will look it up later.
Let's leave that for the end of the lecture.
Now, let's look at an example of compensation from an official document.
Here we see a process for handling data, likely related to purchasing tickets and booking hotels. At some point, money is deducted from the card.
If an error occurs during this deduction, we cannot simply complete the process because if the client's money is deducted and an error occurs, the client will be unhappy since neither the hotel is booked nor the money is refunded.
Therefore, we need to apply compensation. If an error occurs during the deduction, we indicate a compensation event and cancel the hotel booking.
This means that the money is not deducted from the card, and we move to a higher level of the diagram, indicating that if an error occurs during the deduction, the booking will not happen.
Is this clear? If not, please let me know, and I will try to explain it again. If it is clear, please write a plus.
Yes, it is used for error handling.
Okay, since it's clear, let's move on to the next slide, where we will discuss a business case.
I will give you a minute to read it.
The client places an order, the manager receives the order, registers it in the system, and the system checks it against the nomenclature for compliance.
If the order matches the nomenclature, it goes to the economic department, where the cost and timelines for fulfilling the order are calculated.
After receiving the information about the timelines, the order is agreed upon with the client, and a proposal is sent that the client cannot refuse because it is the best offer.
The client decides whether the terms are acceptable. If they are, the order goes into production. If the order does not match the nomenclature or the terms are not acceptable, the client is refused, or other options for processing the order are considered.
This is how the business case looks in text form.
Now, let's see how it looks in BPMN.
Can you see it well? I assume there may be some difficulties, so let's do it this way.
As we can see in our diagram, we have a separate section for what happens on the client's side, but what matters is what happens within our company during the order processing.
We have the order processing, which involves two employees: the sales manager and the economist.
We receive the order from the client, and here we see a pictogram indicating that we have received some data or request.
The first thing we do is have the manager enter the order into the system for record-keeping.
Here, it may not be very clear, but we have a pictogram of a person, indicating that a live person is performing this task.
Next, the order is checked for compliance with the nomenclature, which is done by the system, so we have a pictogram indicating that this is a system task.
As we can see, the system not only processes the order and checks it against the nomenclature but also adds it to the database.
Let's make it clearer.
Next, we have an exclusive gateway that splits our flow into "Yes" and "No." If the order matches the nomenclature, we respond "Yes," and everything proceeds to the economist.
The economist checks the feasibility of fulfilling the order, and again we have a decision gateway. If "Yes," we proceed; if "No," it returns to the manager, who informs the client of the refusal.
But let's not dwell on that for now.
The economist checks the feasibility of fulfilling the order, calculating the cost and timelines. If everything is feasible, we move to the next stage, which is agreeing on the delivery terms with the client.
This is a positive flow of events, leading us to the proposal for the client.
We send the proposal to the client, and what happens next is an event gateway.
There are two possible events: one is a waiting period for the client's decision, and the other is that the waiting period has expired without a response.
Depending on which event occurs, we either enter the order into the statistics of unmet demand and refuse the client or proceed to prepare the contract.
This is a brief overview of how the business case is described.
I will make the screen full size again and answer your questions if you have any.
What level is this diagram? It is descriptive, the second level, which is between the business level and the executable level.
Can an exclusive gateway be used as a fork? Yes, it can.
You can express one process in different diagrams. If you find it easier to work with an exclusive gateway, then use it.
The filled envelope indicates that we received a message, while the one without filling indicates that we sent it.
This is just one way to diagram the business process; there are countless others. You can simplify it by removing the timer or just adding whether we received a response or not.
It all depends on the level of BPMN required in production.
Are there any more questions?
If there are no more questions, I will share some additional materials in the chat.
I remember someone asked about non-licensed options. BPMN has excellent documentation, and I will send the links in the chat.
I hope this helps in your work.
Now, let's get to know the course team. We specialize in system analysis.
I will briefly explain the learning process. The training is conducted online in the evenings or on weekends, but I don't remember the last time I worked on a weekend at Otus.
Usually, classes are held on weekdays, typically on Tuesdays and Thursdays, with some intermediate consultations.
All class recordings and materials are saved in your personal account, and you can return to them after completing the course.
There is a system of homework assignments. The process consists of a theoretical part, followed by a practical part, and corresponding homework to reinforce the material covered.
Homework is checked by mentors, who are also active professionals. You can ask the instructor questions about the materials or clarify any unclear points.
We have Telegram groups where everyone exchanges information, which remains available even after the course ends.
The time commitment for the course is four academic hours per session and 4-8 hours of homework per week.
The course program is updated with each launch based on current requests in the IT field.
Now, let's look at the program for the system analyst course. There are two options: Advanced for experienced individuals and Basic for beginners.
The Basic course is for those who want to try system analysis for the first time or those who have worked in a related field but want to transition into system analysis and understand they need to start from the basics.
The Basic program covers the entire specialization of a system analyst, but it has less depth in technological aspects like API, SQL, and so on compared to the Advanced course.
If you have zero experience in system analysis, it's better to start with the Basic course.
The Advanced course is for those who already understand system analysis and have some work experience that will help organize your knowledge better.
This course is designed for system analysts with 1-2 years of experience who want to elevate their skills in software design.
It covers more in-depth technical aspects of system analysis, including topics like message brokers, SQL, APIs, and everything related.
Now, let's look at the job market for system analysts. I can tell you that system analysts are currently in high demand.
If you check any job site, you will see that system analysis is one of the few IT specialties where demand has not only remained steady but is actually growing.
As of February 2024, there were 1,880 job openings for system analysts on job boards, with over 2,000 for senior positions.
The average salary for entry-level and junior specialists in Moscow starts at around 100,000 rubles, while senior specialists start at 150,000 rubles.
Let's take a look at the typical requirements companies have for system analysts.
Often, they require some technical knowledge, such as understanding object-oriented programming principles and familiarity with databases.
They also expect proficiency with systems like Atlassian, Git, and Confluence, which are not strictly technical requirements but rather an understanding of how IT processes work.
The ability to analyze and process information is fundamental for a system analyst, as they are essentially technical communicators who must find common ground with both business and development teams.
I will give you a moment to read through the expectations for system analysts.
Technical education is often requested, along with a solid understanding of programming and database fundamentals.
From personal experience, I can say that knowledge of SQL is frequently required, but it is not complicated—just the ability to extract information from a database and make queries to view statistics.
Additionally, knowledge of Agile methodologies is often sought after.
For senior positions, companies expect a portfolio, which is not surprising.
For junior analysts, there is more focus on technical knowledge, while for higher-level positions, there is greater emphasis on stakeholder management and soft skills.
It seems that it is more challenging to verify soft skills than hard skills, which can be demonstrated through a portfolio.
I think that covers everything. If you have any questions, please write them in the chat. I will give you about 5-10 minutes for that.
Meanwhile, I will mention that the system analyst specialization starts in a week, so there is still time to sign up and start learning.
I encourage you to join our courses; it will be interesting.
Now, regarding the cost of the courses, I was not prepared for that question.
The cost of the courses is 11,000 rubles in installments, and the full price is 11,200 rubles.
I will send the links in the chat so you can check them out and see if they suit you.
I recommend reviewing the course programs as well.
Is there a way to alternate elements in the BPMN diagram?
I probably won't find a bad way to develop a BPMN diagram, but let me try to find an example.
One moment, please.
I have a very good article on how not to draw BPMN diagrams, which collects all the mistakes that can be made. There are many of them, and I recommend reading it thoroughly; it is very useful.
It starts with the fact that BPMN is not used at all when creating BPMN diagrams.
Then it goes on to errors like signal racing, where interactions between processes may not occur.
It also discusses how to handle situations where a process is incorrectly arranged, such as when an event is overly fragmented into too many events.
At a certain high level, our BPMN diagram should not resemble an instruction manual; it should describe a business process.
There are also examples of when all events converge into one, which is not officially prohibited by the notation, but it is not the best practice.
I strongly recommend reading this article and saving it as a bookmark; it is excellent.
Are there any more questions?
I don't see any more questions. Thank you all for attending today's open lesson.
Thank you for your participation and interesting questions. I look forward to seeing you at the next open lesson or in the course.
Please fill out the survey; it helps make the lectures more accessible and better.
Thank you all, and have a good evening and a great week. Goodbye!