SOP (Standard Operating Procedure) is a very old method of steps to guide operations. It is commonly used for industries that requires a lot of standardisation. With digital transformation, it is highly anticipated that RPA (Robotics Process Automation) will replace many of these SOP. Sadly, RPA is far from being a replacement.
RPA automate Poor SOP
An ideal RPA is an automation of SOP without user intervention. RPA does not differentiate between good or poor SOP. If the SOP is flawed, RPA will amplify that error by a large magnitude. This is because humans could be fixing the poor SOP unknowingly. Therefore, you will be faced with the risk of creating a large issue from RPA.
The Real SOP
Documented SOP may not always paint a true picture of the SOP on the ground. Majority of documented SOP are outdated and not relevant. This is very obvious with system where the SOP is disconnected with the system user guide. In this case, operational users evolve documented SOP with system user guide into a “Real SOP”. This SOP is usually only known to operational users. Thus, it is not surprised that RPA is done for the wrong SOP.
For all the hype of RPA, it cannot be a replacement of SOP. Instead, it is more worthwhile to invest in business process re-engineering (BPR) to improve the SOP.
Business analysis is a fun field because you get to know all kinds of requirements. One of my favorite is “Want All Requirements”. So, what does this mean? This actually refer to the users who want requirements that can cover all kinds of scenarios in the world. In reality, most of scenarios are not applicable. Thus, the user cannot articulate how the requirements will be.
I usually relate such requirements to abstract art. This is because the requirement is subjective to each user point of view. It is so abstract that you cannot really define. It is best to place the requirements in your backlog until you collate enough perspective to interpret with confidence. If you are using waterfall, this is best added to your “parking lot” and taken out of your critical path.
The Sad End
From my past experiences, implementation of these type of requirements always end up unused and unwanted. Majority of these requirements are “nice to have” and strongly insisted by non operational users who may have see such features in other products. Without any linkage to SOP (Standard Operational Procedures) or knowledge of end users, these requirements will meet a very sad ending.
A rule of thumb is to use SOP as a sanity check to ensure requirements are implemented as required. It is a total waste of time, cost and efforts to fulfill “Want All Requirements” knowing it’s sad ending.
Today, I encounter another interesting requirements which state “depends on customer”. Being in project implementation for so long, I am still amused by this response. Why are there such requirements? Do not be surprised as such response is actually very common in Asian countries.
关系 as requirements
Asia cultures plays a big part in influencing the customer requirements. The “关系” aka as customer relationship is an unseen and very strong force. This practice is much prevalent in China, Japan and South Korea. It is no surprise that requirements can change upon customer requests. Naturally, it create challenges for the organisation as system is driven consumer customisation.
Customer is King
“Customer is King” is very common in Asia. With lower switching cost and labour cost, customers tend to be more fickle minded in Asia than American or EU countries. With the differences of leverages, organisations tends to accommodate customers for quick wins. Digital transformation also make it easier for customers to migrate their data across different platforms.
In Asia, requirements are driven largely by cultures. Power is a common play by customers to get what they wanted and as requested. You will usually need local help to elicit and mitigate such requirements. Only then, you can satisfy your customers and gain their trust.
Have you ever encounter vague requirements? What are usually the issues? I will have a standard strategy to handle vague requirements. This is a quick and systematic approach to manage such requirements.
Identify the stakeholders for the requirements.
Get sample data for the requirements. This can be existing data or copies of excel records.
Consolidate user communications and understand interactions of users and the requirements and the sample data.
Agile or prototype to elicit sample data or to clarify the requirements.
Separate clarity and vague once you identify each part of the requirements.
You should be able to proceed on the clear requirements and put the vague part into the backlog.
Iterate the approach from Step 1.
Requirement gathering is never straightforward. Those documented are usually clear requirement while the vague part exists somewhere out there. It takes a lot of practice to clarify vague requirements. You can consider to approach it in a systematic and agile manner.