Introduction
While in article Build a Business Process Management System – Stage of System Building we have defined that the 1st stage of building a system is Modeling, in article Build a Business Process Management System – BFs-WAITER Pivot Table we have further named the content or directions that we should included in the Modeling stage as BFs-WAITER.
No matter how comprehensive the model can reflect the intricacies of the real world, we should have a tool to effectively transform the model to an executable system with a human interface, namely bGraph in Diamond Digital Marketing Group. Before we dive into the functionality of the bGraph, in order to sharpen the effectiveness of the it, it is always a good practice to enumerate the problem patterns that we encountered when using traditional tools.
Problem Patterns in Modeling Stage of BPM Building
Polymorphism in communication
In the very beginning of a Modeling Stage, the Business Analyst (or Consultant, whatever you name it) will conduct an interview to the stakeholders of the target company in order to collect the information relating to the target business process. Any kind of documentation collection, verbal description, or even on front line field observation is carried out by the Business Analyst to be familiar with the target business process.
After the Business Analyst finished the interview, he/she should spend time on organising the data into information and pass it to the System Analyst (and his/her programmer team) and bring the BPM System Building stage to Stage 2 (Standardization).
However, different target businesses, different Business Analysts or different clients, will always use different wording or language to describe the same concept. For example, while the client will refer to the product they are selling as Product, Business Analyst will name the Product as SKU. Another example is that the wording Last Name is a synonym of Surname, which can be used interchangeably.
On the contrary, Business Analyst and Client will use the same wording to refer to different business concepts. One of a typical example is the term “Client“. In a manufacturing industrial chain, no matter if you are the Manufacturer, Distributor or the Retailer ,you will always name your downstream as “Client”. During a BPM System Interview, a Business Analyst needs to pay double attention to figure out who (Manufacturer, Distributor or Retailer) the term “Client” is referred to. As a professional Business Analyst, we will name them as the Brand, the Merchant , the Retailer and the End User respectively in order to uniquely identify them.
This polymorphism in communication not only occurs between the Client and Business Analyst, but also the Business Analyst and the Programmers. The more different wordings are used , the more resistance will be derived during the communication.
Therefore , a communication protocol which can synchronise the wording is necessary.
Duplicated Analysis Wordload with Different Clients
No matter which industry , country or business model the client is in, a CRM system will always share some common properties and features.
For example, the client will expect a standard CRM to have a Contact module which at least has First Name and Last Name as the properties of the object Contact.
As a Business Analyst , in a BPM System Interview, you may not want to waste both you and your client’s time to go through what common properties a CRM System should have, which those common properties may properly went through many times in the previous similar project.
On top of it, it is a must for a CRM to have a Country field for the users to fill in the nationality of the client. As a Business Analyst, you may not want to go through the comprehensive list of countries again and again in different projects.
In this sense, it will be a great time saver if we can have a CRM System Building Template which comprises all the common properties of a standard CRM.
No Trigger On Searching Similar Functions in Previous Project.
Even though you (as a Business Analyst) are driven by public-spiritedness that you already encapsulated a comprehensive Country list as an array for next project use, how can the other Business Analyst , or even the future yourself, remember or realize that you have already created the Country List before?
Even worse, the concept Countrycan and will occur not only in CRM , but also almost any kinds of system like Project Management System, Eshop or Booking system. What will make (i.e. trigger) the programmer who is going to build a Booking system think that he can refer to the previously built CRM system to find out the Country List? If he/she cannot realize that a Country list already existed in some other project blueprint , he/she may probably will spend time to do it again, what duplicated the cost of development.
If the next Business Analyst does not realize that you have already done this before, he will not search for the Country List. There is always a gap between searching for the solution and the solution itself.
Unique Wordload with Different Client
Although there are many properties in common in a CRM system, there are different properties too. For example, while a trading company may expect a Contact is defined as a Company or Organisation which should have Company Name field, a Beauty salon may expect all their Contact is an individual which should have First Name and Last Name field.
It is necessary for us (Diamond Digital Marketing Group) to have a system which stores all the common and differences of building different systems for different clients.
Streaming (vs Batch) BPM Building Process
To continue the example of CRM system building, as a Business Analyst, even though you have carefully listened to your client and clearly defined the common and different fields of the target CRM system after the 1st interview, it is very unlikely that you can hit a home run to gather 100% of the expected features and properties of the target CRM system in the 1st interview. While a system building is a lengthy project which always lasts for months or even years, the business environment is probably changed from time to time during the target CRM system building period, which will also affect the features and properties of the target CRM system.
Imagine a scenario as below:
In Day 1 the Business Analyst suggested the field First Name and Last Name to be included in the Contact Module of the target CRM system. In the very next Day 2 , the programmers have already kicked off the program coding workload and created a Table in the Database , as well as the First Name and Last Name Field in the user interface.
However, in Day 3 due to a new Marketing Manager (a “she”) on board from the client side, she perceived that the fields Maiden Name and Middle Name are common sense and should also be added into the Contact Module. While she passed this request to our Business Analyst, and then our Business Analyst passed this request to the programmers on Day 5 by directly appending 2 New Columns Maiden Name and Middle Name in the CRM system Building Blueprint Spreadsheet.
This behavior will make the programmers confused because (if you have paid attention to our story) the programmers had already completed the program coding workload in Day 2, how can they realize that 2 new columns are appended to the CRM system blueprint spreadsheet which they had just brought to coding?
Even though you may suggest that the Business Analyst can notice the programmers after they had done any adjustment in the blueprint spreadsheet, due to the fact that the specification of the blueprint is in fact under a streaming status which can be and will be changed from time to time, it will be impossible for the programmers to build the system based on a ever changing blueprint. Do you expect the programmers to click if there is any modification in the blueprint spreadsheet every 1 hour?
In this sense, a streaming oriented system blueprint is necessary for the communication between the Business Analyst and the Programmers, instead of a traditional system building blueprint which only reflects an instantaneous time spot.
This streaming oriented communication mechanism not only satisfies the modification need during the development status, under a DevOps concept, but also in the future after the system is brought to production due to the fact that the system is a living organism which is dynamic to the ever changing business environment. The traditional Batch (or Versioning) oriented can not satisfy in this sense.
Mobility of the System Building
As an experienced Business Analyst , you can imagine that no matter how you ask your client to submit an expected new field or new feature of a system via a submission form, the client may probably not follow your instruction and simply send that expected new field to you via email or even WhatsApp.
After you receive the request from the client, instead of only simply forwarding the request to the programmer to handle, as a responsible and professional Business Analyst , it is our duty to validate whether or not the new request is a valid request (most of the time the request is invalid).
For example, if the Client complains in the Contact module of a CRM that the field Sex is missing in the Form in the user interface, you should first of all go to the project blueprint to check whether the field Sex should be included in the blueprint. If the Sex field can be found in the blueprint but not in the Form in the user interface, then you should contact the programmer to fix it up. But in the real world, most of the time after you conduct the checking, you will realize that the field Sex is in fact named as Gender in the Form in the user interface of the Contact module.
Can you imagine this kind of back and forth checking and non productive communication is the main cause of eroding the time on production.
Think about if you are handling 10 BPM system building projects on hand , how can you quickly open a system (if there is any!) in your mobile device to check whether the complaint from one client is valid or not? If the complaint is valid , how can you quickly send an instruction to the programmer to fix the bug, provided that you are not seated in front of the desktop but instead on the way travelling to the next client meeting?
If you find the complaint is valid and is a critical path of the project which if you don’t fix up the bug immediately the error will cascade to the next node of the critical path of the project which in turn derives an irreversible catastro, you cannot afford to notify the programmer after you finished the meeting.
A powerful steaming BPM building system is necessary for catering all the mobility needs of the communication.
Leave a Reply