Diamond Digital Marketing Group

Tag: MSC Matrix

  • Build a Business Process Management System – BFs-WAITER Pivot Table

    Build a Business Process Management System – BFs-WAITER Pivot Table

    Introduction

    Recap from the article Build a Business Process Management System – Stage of System Building that the MSC Matrix (Modelling – Standardisation – Coding) describing different stages of building a system. In this article, we dive into how we observe the real world to do the Modelling by using the BFs–WAITER Pivot Table.

    Definition

    What is Pivot Table

    The “pivot” part of the Pivot Table comes from the way you can “pivot” or rotate your data to view it from different angles. It’s like being able to look at the same set of numbers from multiple direction. Please find comprehensive explanation in the article What is a Pivot Table.

    What is BFs-WAITER Pivot Table

    BFs-WAITER is a DDM Terminology which is the acronym of all the dimensions when describing a Business Process Management System:

    Business Rules

    Business Rules are the if-then-else conditional logic which the user of the system , or the system itself should comply with.

    For example, when you insert an email address in the Email Address Field of an Contact Us Form, the system will show an alert of “please insert an valid email address” if the “@” character is absent inside the email address. This is an Email Validation Rule that the web application developer will usually use.

    Besides the rules in programming, we can also find other rules in the business world. For example, you want to adapt a bundle discount in your business that if the clients buy both 1 shoe and 1 skirt in 1 order, they will enjoy a 10% discount. This kind of if-then-else condition logic can be named as Discount Rules, which is classified as one of the Business Rules. While you can and should customise the own business rules specific for your own business, there are some common Business Rules that we should cater in most frequently:

    1. Shipping Rules
    2. Discount Rules
    3. Coupon Entitlement and Redeem Rules
    4. Email Validation Rules
    5. Password Validation Rules
    6. Return and Refund Rules
    7. Pricing Rules
    8. Traffic Routing Rules

    Fund Flow (or Cash Flow)

    To be precise , the term Cash not only refers to the currency note or the debit balance in your bank account, but also the credit balance or any payment token. As there are too many ways to represent a payment, we name it all under the term Fund.

    Infact , Fund (or Cash) Flow, Information Flow, Stock Flow and Work Flow are 4 flows which we mentioned very often when describing a business process. Without surprise, Cash Flow is not going to be absent in our model.

    Stock (or Service) Flow

    The lowercase “s” inside the acronym “BFs-WAITER” means it is optional. Whether you want to record the Stock or Service Flow depends on if you should do stock (or service) taking on the product or service you sell.

    Work Flow

    Quoted from Wiki the definition of Time:

    Time is the continued sequence of existence and events that occurs in an apparently irreversible succession from the past, through the present, and into the future.

    While I am not going to (and not capable of) triggering the debate on what Time really is, referring to wiki, time is a continued sequence of Events.

    In a Business Process Management System, there is no better way to describe the Business Process than in the aspect of Time. While time is best to be presented in terms of Events, Events can be regarded as Steps or Procedures inside a Business. For example, in a Self-serve Cashier Register Checkout System :

    1. Client press the Start Button
    2. Client scan the Barcode over the package of the goods
    3. Product Quantity and Price shown in the Screen
    4. Client press Checkout Button
    5. Client pick a Payment Method and Pay
    6. Client get the Receipt printed by the Cashier Register Machine.

    Above is a typical but straight forward example on describe a Business Process. In most of the time ,Events are far more complicated than we can imagine. Allow me to introduce some concepts that you should master before you move forward:

    Backbone Events

    Back to our previous Cash Register Checkout System example, allow me to detail it as below:

    1. Client press the Start Button
    2. Client scan the Barcode over the package of the goods
      • If the Client want to remove the items, then ….
    3. Product Quantity and Price shown in the Screen
      • If the Client buy more than one item of the same SKU, then ….
    4. Client press Checkout Button
    5. Client pick a Payment Method and Pay
      • If choosing Apple Pay, then ….
      • If choosing Credit Card, then ….
        • If the Credit Card failed to process the transaction , then….
    6. Client get the Receipt printed by the Cashier Register Machine.
      • If the Cashier Register Machine is out of receipt printing paper, then….

    You can imagine in reality there are tons of if-then-else branches which can be happening in any of the steps. In some cases you cannot even imagine this scenario will happen until it really happens in front of you in real life. For better communication and project management purposes, we should in first priority identify the shortest path from start to the destination of the business process and skip all the possible if-then-else branches. (i.e. Clients get the receipt in the above example) We called this shortest path Backbone Events.

    Scenario

    Scenario means one of paths within all possible combinations of outcome which can but may or may not happenⓘ. To make it simple, let’s illustrate with an example:

    1. Finished input the Product Quantity > Choose Apple Pay > Transaction Success
    2. Finished input the Product Quantity > Choose Apple Pay > Transaction Failed
    3. Finished input the Product Quantity > Choose Credit Pay > Transaction Success
    4. Finished input the Product Quantity > Choose Credit Pay > Transaction Failed

    In the example above, while there are 3 steps , which :

    1. First Step have 1 option value
    2. 2nd Step have 2 option values
    3. 3rd Step have 2 option values

    To do the maths, there will be 1 x 2 x 2 = 4 possbile outcomes, and we call each of the outcome a Scenario.

    Imagine if there are 10 steps and each step has its own 2 option values, there will be 210 , which is equal to 1,024 Scenario. Addressing all these scenarios is already a huge challenge , not to mention catering them one by one.

    Recall the article Build a Business Process Management System – System Index Concepts, A good System caters all the scenarios after interacting with the environment, which is exactly what we have mentioned in this paragraph.

    Authority

    When you login an application, you are authorized to login after you insert a valid password. When you want to open the door of your home, you are authorized to do so only if you a have valid key. The password and key in these examples, are the Authority that we should have to carry out the action.

    The Authority is usally presented in following ways:

    Role Base Access Control (RBAC)

    It literally means that the Access Control is based on the Role of the user. For example, Only the Role of Admin in the website can install a plugin, while the Role of Guest User cannot.

    Session (Time) Base Authority

    For example, you rent a meeting room in a shared office for 2 hours. That means you are only allowed to access the meeting room within these 2 hours. After this 2 hours (i.e. Session), you are not authorized to access the room.

    Authorization Token

    In ancient times when there was no Facebook or Instagram, it was extremely hard for everyone in the country to know (in terms of the real face) who you really are. The only way to justify that you are the king of the country is to show some kind of Totem, like a imperial jade seal, which is the emblem of the authority for the local officer of the country to recognize the king. 

    Imperial Jade Seal as a Authorization Token
    Imperial Jade Seal as a Authorization Token in Ancient China

    Authorization Token is the same logic as the Totem in the ancient world. No matter who possesses at that moment, he/she is authorised. In morden world, whoever get the remote control (i.e. the Totem) of the TV set in the living room, who is the king/queen.

    In the computer world, we usually apply Authorization Token during the communication between system and system (i.e. not between system and human). For example, if you want to let your WordPress website to fetch the Instagram Feed directly from your Instagram Business Account, you should generate a Access Token (i.e. Authorization Token) from Instagram Business Account and pass it to the WordPress Website.

    While there is a rare case the Authorization Token is presented in a physical form, most of the time it is in fact nothing more than a meaningless cluster of strings that you keep in a secret computer file.

    Information (Document) Flow

    Recall the article Relationship between Human Learning and Data Structure , Data is the signifier (i.e the pointer) of the signified (i.e underlying objects).

    For example, the Sales Invoice is the signifier of the happened event of the delivered material products (i.e. the signified) , while the Payment Receipts is the signifier of the Cash material currency note (i.e. signified) paid physically (i.e. pay offline) to settle the Sales Invoice.

    By simply operating the Data , rather than operating the physical underlying objects, we can speed up the analysis of Business Process a lot.

    When a large amount of pieces of related Data bonded together bringing the user a meaningful value, they become Information.

    When we describe the Business Process in terms of information, we call it Information Flow.

    While most of the time the information will be presented in or delivered via a Document as a media of convey, we therefore use the terms Information Flow or Document Flow interchangeable.

    Whenever you master the information flow, you can get use of them by facilitating your decision making process in a timely and accurate manner.

    Tools

    A computer , a laptop, a Cashier Register Machine, a Camera, a PDF Converter Online Website, a Credit Card , can all be regarded as Tools, whatever you name it.

    Entity

    In legal terms, a legal entity refers to any organisation or individual with legal rights and obligations under the law. Such entities can enter into contracts, initiate or face lawsuits, and own assets in their own name.

    We pick the term Entity (instead of the term Person) because it may have both individual person and organisation , or somtimes even a system or an algo (how complicated this world become!) involved in the Business Process.

    On top of that, while in rare cases we can specifically address a particular person in a Business Process (for example, Anna, Ann, Joan , etc) , very often we can only put the Entity Type (instead of the Entity Instance) inside the Business Process. For example, Client, Admin Manager and User are the Entity Types we will describe in the Business Process due to the fact that we don’t know in advance which name client really is in the planning phrase.

    Risk (Problem Pattern)

    While the concept Risk is easy to understand, the term Problem Pattern is used in Diamond Digital Marketing Group very often, which is indifferent to Risk.

    In order to manage the Risk, we cater the following aspects:

    Identity the Risk (i.e. Frequency of the Risk)

    Some risks are easy to address. For example, human error on data entry. Nevertheless, some risks are invisible and can hardly be addressed, or even hardly be classified as risks. For example, when your salary is USD$50,000 per month , you are unlikely to realise that your ability is in fact worth USD$120,000 , which means you are risking USD$70,000 per month and you have no idea at all because you have already satisifed when you reached USD$50,000 per month.

    Probability of Risk

    Even if there is a chance that your business may suffer from alien-attack to the planet, you are more likely to cater to the risk of a fire accident compared with the alien-attack scenario. The chance (i.e. probability) that the risk happens will highly affect the priority that we handle the risks.

    Magnitude of Risk

    While you can foresee there is a high chance that the plastic bags which can be freely grabbed in the cashier by the client will be abused by the clients, you may probably not to cater the risk, at least not in a higher priority than catering the risk of the Google Ads campaign which brings the sales turnover to your business being restricted.

    Radius of Risk

    In hollywood movies, whenever there is a public health affairs which the zombie virus is going to spread out from the lab, the supervisor of the hero will make the hard decision to quarantine the people to the lab in order to control the radius of the virus spreading distance, in sacrifice of the survival chance of the people who are stuck in the quarantine zone. At this moment, the hero will stand up and rescue the innocent.

    Quantifying the Risk

    The first step of automating anything is by quantifying it. Quantifying the Risk is a combination of the Frequency, Probability, Magnitude and Radius of the Risks. The arithmetic operations will be explained in future articles.

    Putting BFs-WAITER into Pivot Table

    You can visualize that all the 9 Components (i.e. B/F/s/W/A/I/T/E/R) are in fact the 9 dimensions in the Pviot Table.

    It also implies that whenever you want to mention a single Step (or Event), you should at the same time mention the other 8 dimensions in order to coordinate that single Step (or Event). While it is really sophisticated for human beings to comprehend all the data points by a normal Table, a Pivot Table is a good presentation which visualises the relationships among all dimensions in every Data Point (i.e. a Cell in a spreadsheet). This significantly assists the communication among the stakeholders including client , programmor, system engineer, web developer , salesperson , system users and a lot more.

    Separate between modelling and standardization

    In BFs-WAITER, while Modelling means to enumerate all the option values of all the components , says all option values of Documents and Entity Type, Standardization means how to analyse the relationships among each component and interconnect them.  

    Modelling and Standardization are 2 different processes which will be carried out by 2 different roles in different time. While Salesperson or Consultant are more prone to listen to the clients in a sales meeting in order to enumerate the system requirements , documentations or stakeholders (i.e. Entity), System Engineer will on the other hand focus on logically connecting them in order for a meaningful and logical relationship.

    While it is much easy for the Salesperson to adapt a normal Table to records all the option values of all the components during a consultation meeting, a Pivot Table is a much more helpful tool for a System Engineer to connect the relationships and switch it among different presentation views (i.e. Pivot by different dimensions) within a second.

    In Diamond Digital Marketing Group, we will apply the BFs-WAITER Pivot Table as the main tool for Business Process Management System development. While this article is mainly focusing on the Meta System level in System Index , and the Standardization in MSC Matrix, any hands-on operation will be left for future chapters.

  • Build a Business Process Management System – Stage of System Building

    Abstract

    The Meta System aims to create a system that can, in turn, build other systems. This implies the presence of repetitive patterns or tasks that can be identified and reused within the Meta System. In this article, we will elaborate on and evaluate these patterns.

    Stages of Building a System

    First thing first, the most challenging part on writing this article is that as we are writing the guideline on how to build a system to build a system, it is really hard for both the reader and the author to address which System Index (i.e. System , Meta System , Meta System2) that he/she is reading/writing. The only suggestion to keep your mind clear is that , read this article only when you get 100% energy fully charged.

    While discussing how to build the Meta System, we first need to address how to build a system itself. Regardless of the system you’re building, you will need to consider these four objectives, and the order in which you achieve them is important. Allow me to introduce the MSC Matrix (Modelling-Standardisation-Codingⓘ ) as below:

    Stage 1 – Modelling

    Let’s start with an example , assuming that you are the Software Engineer who is responsible for building a Cashier Register System for your MNC scaled supermarket.

    As mentioned in previous article that a good system can cater all possible outcome , which the system interacts with the environment. Allow me to named the term “all possbile outcome” as Sample Spaceⓘ,

    Before we jump into the execution level to discuss step by step on how to enumerate every single instance within the Sample Space, I would rather in theory discuss what is and when we need to do the Modeling.

    If the objective of us (i.e. the Cashier Register System) is to cater all possible outcomes (i.e. Sample Space) interacting with the environment1 (i.e. the environment of a MNC scaled supermarket), finding out the Sample Space will be the prerequisite before every other steps.

    However, as a human being, bounded by our mortal presence and limited compute power, it is extremely difficult , if not impossible , to enumerate all the instances inside the Sample Space. For example, instead of describing how the clients bring the goods into the cashier conveyor belt, are you going to write an Apocalypse Handbook describing how to survive during an alien attack during the opening hour of your supermarket, as the very 1st presentation session to your C-Suiteⓘ boss?

    Although you might think there is a chance to happen (which i am on your side, bro!) and you may have the chance to become a superhero, you may not dare to do it to risk your career path in this company. If you nod your head, it means that you are filtering what is appropriate and what is not appropriate to put into the system, which is named as Modeling.

    You may challenge that human decision is always paired with a risk. While you start filtering , it is no longer all possible outcomes, which I totally agreed with. However, as stated before, due to the limited resources , we need to strike a balance between the Utopia and feasibility. The more experienced the Software Engineer is , the higher chance that he does the modeling which is close to reality. It is more of an art than a science.

    The rule of thumb is simple:

    The higher chance it will happen , the higher the priority to be recorded.

    If you are “I.T.” enough, you can draw the Entity Relationship Diagram to do the Modelling. If you not , simply using a Google Spreadsheet will be good enough for enumerating and communicating all the factors and components  

    Stage 2 – Standardization (SOP)

    Once you have do the Modelling by filtering all the relevant steps, concepts or objects in priority, you can do the Standardisation. In business world , you can also refer this standardization action as SOP – Stand Operation Procedure.

    Whatever you name it , Standardisation (or SOP) is a procedure which you can apply anywhere within your business scope. For example, you can standardise the procedures of the self-serve checkout function in the Cash Register System as below:

    1. The customer brings the goods in front of the Cash Register
    2. The customer picks up the one goods and uses the scanner embedded in the Cash Register to scan the barcode printed in the package of each goods.
    3. The product information will be shown in the screen of the Cash Register
    4. The customer presses the Checkout button on the screen, and brings him to the Payment Screen.
    5. The customer chooses the Payment Method, Apple Pay for example.
    6. The customer scans the Apple Pay QRCode shown in the screen of the Cash Register by the QR Code scan of his/her smartphone.
    7. The checkout process is successful and the receipt is printed

    Although the steps mentioned above is only the backboneⓘ procedures (as enumerating the Sample Space is not the focus of this session, i will bypass this exercise) , the above 7 steps will be happened almost every time for every single customer bringing the goods in front of the self-serve checkout Cash Register.

    In this stage, while you are standardising the procedures , please do not rush to think of or work on any programming or coding stuff. Especially when you have a programmer background with solid hands-on coding experience, it is very tempting for you to dig into the code and write any kind of framework , database or UI to start building the software. Because in your mind you may think that Coding means automation, and automation means efficiency. You are wondering why the frontline staff need to spend double time on doing the same steps while you can automate them via coding.

    Indeed you are not wrong. However, you are not correct either. Because Coding is a all-or-nothing game. You cannot write 80% of the code and bring it to production stage. Any of a single tiny bug might bring the application to fatal error. And then you need to condense all your energy into fixing that bugs. Once you sink into coding, you will spend most of your time focusing on coding for a single step of the whole system, which in turn you cannot get use of the man hour of your frontline staff and can only let them idle because they do not know what to do without any standardised procedures for the whole picture.

    Allow me to illustrate this concept with Bingo Theory

    Bingo Theory In Business Process Management Development
    Bingo Theory In Business Process Management Development

    Bingo Theory is a terminology invented by Diamond Digital Marketing , which is a all-or-nothing concept stating that if someone does not finish all the steps in a business line (i.e. Say Bingo! in a Bingo game), all his effort will be in vain no matter how much he had already contributed.

    Illustrated in Figure 1, if there are 5 Steps to say Bingo! in each stage , we can conclude that:

    1. In Modeling Stage , due to the fact that we do not enjoy the efficiency brought from standardising or coding (i.e. automation) the procedures, the cost of each step will be £5 , which brings a total cost of £25 to say a Bingo!. As long as the reward of Bingo! is £30, there is still a £5 profit in Month 1.
    2. In Standardisation Stage, due to the fact that we have to do all the 5 steps in both Modeling Stage and Standardisation Stage in each step, therefore the total cost per step is £5 + £3 = £8. Therefore you will get £30 – £40 (£8 x 5) = £10 Lost in month 1.
    3. In Coding Stage, same logic as Standardisation Stage, the total cost per step is £5 + £3 + £1 = £9, and therefore you will get £30 – £45 = £ 15 Lost in month 1.

    Based on Figure 1 ,you can deduce that when the time goes by (i.e. Month 2 and 3), your business in Coding Stage will get the highest profit due to the fact that it can enjoy the efficiency generated from coding (i.e. automation), provided that your company have sufficient fund (i.e. -£15 Lost in month 1 , and -£5 Lost in month 2) for you fill the deficit for your business survival. For sure, it is also not the greatest decision for any business to stay forever in the Modeling Stage to gain the minimum profit due to absence in Standardisation and Coding.    

    While striking a balance between efficiency and sustainability is case by case, If you are similar to us without solid external financial support , it is suggested to go for Standardisation before directly jumping into the Coding Stage. On the contrary, if you have external financial support, please contact us and invest in us!

    Even worse, while you are drowning in Coding , some of the smarter frontline staff might find their own way to carry out the Cash Register procedure based on their past experience, which brings your business to risk. While your whole business now all rely on the frontline staff, you may have either wrong procedures which cannot cater the backbone procedures, or you may have many ways to do the backbone procedures due to the fact that each different smart staff may have their own working style and hence suggesting different procedures. Regardless which way it takes, it will in turn either generate errors or arguments , i.e, extra cost incurred.

    Therefore, please be reminded again that in this Standardisation Stage, what you should do is simply to standardise the procedures making your Cash Register System functional.

    Instead of coding, you can standardise the procedure in an Google Spreadsheet, in a Google Document, or even verbally or taking a video to record the step by step actions, depending on what way you and the users are comfortable. The purpose of the standardisation is to avoid the miscommunication due to the ambiguous definition of the benchmark of the input or output of the task. Manually input or output will be good enough in this stage.

    Besides, there is a big difference between System and Software. Imagine 60 years ago before computers were popular, the supermarket with a manual Cash Register already existed. Even without the aid of computers, they can still run properly, if not as smoothly as nowadays.

    In this sense, standardising all the procedures with manual input will be good enough for this stage. By standardising all the steps within the Checkout procedures, you can eliminate most of the errors generated by humans, which in turn free your hand from error handling and human resources training.

    By using the extra time earned from error handling, you can spend the time profit you saved to do the coding stuff in the next stage.

    And I can officially and seriously tell you putting the Standardisation Procedures between Modelling and Coding is the key to success in running a business. When you read through the financial reports of some of the leading companies, you might realise that their spending on R&D (Research and Development) can always be absorbed by their profit, which makes their research and development sustainable. If your whole business consumes most of your resources on developing the coding and automation of the Business Process Management System, the daily operation will be ruined. On the contrary, if your business keeps staying on Modeling Stage, your business will only become a theory which can never be realised, or at least the slope of the development curve will grow too gentle and behind your competitors.

    Stage 3 – Coding

    Coding Stage implies to automate all the standardised procedures of the Business Process Management System as much as you can by any kind of programming language , or even simply Google Spreadsheet Formula.

    Bringing the company to this stage is a milestone in which you can outperform your competitors. Although I am not going to describe the step by step guideline in this article, i would like to share some rules of thumb of the Coding Stage as below:

    1. Automate the procedures which happen most in 1st priority. 
    2. Automate the procedures which is easiest in coding in 1st priority.
    3. Rhythm between operation and development is the key to success in business. Always get a “C” grade to survive first, and get a “A” grade with the spare resource. Perfectionism always deficit first. If Apple , the manufacturer of iPhone is a perfectionist, it should only have iPhone 1 and not iPhone 16 because iPhone will wait until all the features are “perfect” before it is launched in the market.

    In conclusion, each record (or row) in Model-Standardise-Coding Matrix is for a specific objective in the Business Process Management System. If you have 10 steps in your Business Process Management System, you do not need to do all the 3 steps (for example) in the Modelling Stage before you can move to the next Stage. I personally suggest a horizontal move (Table 1) before vertical move (Table 2) due to the based on Bingo! Theory. Nevertheless ,whether you go vertically or horizontally is dependent on the resources and manpower capacity of your company which is a preference and not right or wrong.

    Stage / StepStep 1Step 2Step 3
    ModellingDay 1Day 2Day 3
    StandardisationDay 4Day 5Day 6
    CodingDay 7Day 8Day 9
    Example of Horizontal Model-Standardisation-Coding Matrix (Table 1)
    Stage / StepStep 1Step 2Step 3
    ModellingDay 1Day 4Day 7
    StandardisationDay 2Day 5Day 8
    CodingDay 3Day 6Day 9
    Example Vertical Model-Standardisation-Coding Matrix (Table 2)
    1. Refer to article Build a Business Process Management System – System Index Concepts
      ↩︎
Diamond Digital Marketing Group