Adoption of the SIPOC methodology has transformed customer engagement and driven project success while respecting time and budget constraints.

 

It is important to have some basis of scope when initiating a digitalization initiative so that the manner in which it will be leveraged to enact positive change and thus the value it brings is well understood by all involved.  An unclear value proposition will likely lead to assumptions, unmet expectations, last-minute changes, and poor solution acceptance - in short, an unhappy customer.  Projects executed in a purely agile manner often lack overall goals, clear scope boundaries, and a comprehensive project roadmap.  As a result, these projects have an unclear definition of completion, exhibit cost overruns, and lead to unfulfilled customer expectations.

Historically, the common approach when starting a new implementation initiative was to create documentation up-front describing the solution to be built.  This entailed creation of a user requirements specification (URS), functional requirements specification (FRS), and detailed design specification (DDS).  And, it always tended to be a struggle getting these documents authored and reviewed, for the following reasons:

  • The delineation between the content to be put in the URS vs. FRS is often unclear, which leads to repetition and/or gaps.
  • It is extremely challenging to plan out all the specific functions to be provided by the solution up-front.  Seeing certain functions implemented in the application will naturally spark ideas, suggestions, or corrections of misconceptions.  It is hard for the customer to sign off on a screen mockup or description of an interface without sufficient understanding of what processes it enables and how it will actually be used day-to-day. 
  • Defining a detailed design around uncertain functional requirements up front proves even more difficult.  Implementations often morph to leverage new ideas and react to realizations that occur while implementations are in-flight.  For example, maybe two stored procedures can be rolled into one generic one that covers multiple screens, or an additional REST API call is actually needed that was not originally anticipated. 
  • Even worse, the team may compromise and create a functional design specification (FDS).  This provides a high-level description of the functionality provided by the solution and the design of the solution to enable the functionality, poorly conveying both aspects. 
  • Customers feel that they have one chance to get everything they need into these documents, or else the solution will be locked in and it will be a battle making further changes.  As a result, the review cycles are lengthy and overall progress on the initiative is delayed. 

 

Once this documentation is created, it tends to be lengthy and difficult to comprehend.  The user cannot visualize how the solution actually looks and feels.  Non-technical reviewers will not understand the technical aspects, and technical reviewers may not understand or care about the functional 'look and feel' aspects.  Redlines and comments are numerous simply because clarification is needed.  Or, the key customer stakeholders do not even bother to review the documentation.  When it is time for go-live, even though the specifications were approved, the solution does not meet expectations because the specifications were not fully understood, were incomplete, or were not even read. 

Further, the documents become stale soon after implementation commences as the implementation team often deviates from the specifications (with good intentions) but fail to revise them to reflect the as-built solution.  By the end, the specifications only loosely represent what was actually delivered and are of little value to anyone. 

We find that the most critical aspect of the initiative for customer stakeholders to understand up-front are the business process scenarios in which the solution will be leveraged to facilitate day-to-day operations.  If stakeholders can visualize how the solution will integrate into their work processes to provide benefit, the specific details as to how exactly it will look, feel, and function can be sorted out throughout the agile sprint execution process.  Well formulated business process scenarios achieve the following goals:

  • Be easily understood by non-technical stakeholders
  • Be documented in an efficient, repeatable manner
  • Be technology agnostic.  The business process scenario should refer to various business systems at a high level (MES, ERP, LIMS, control system, etc.), but not delve into the nuances of applying a specific platform or technical solution, as this will be confusing to non-technical reviewers
  • Establish 'guardrails' concerning the solution to be provided, so that the intended processes to be facilitated by the solution are clear, reducing the possibility of future scope creep
    • Both typical (sunny day) and exception (rainy day) scenarios should be captured
  • Provide a basis upon which more detailed user stories can be built.  User stories should be matrixed to business process scenarios so that the goal and reasoning for each user story is clear
  • Highlight required user-to-system and system-to-system interactions, which can be leveraged when building more detailed technical documentation (architecture diagrams, value stream maps, etc.)

 

The RoviSys MES center of excellence has adopted the 'SIPOC' methodology for the definition of business process scenarios.  This is an industry standard methodology that has been adapted to better serve the needs of our MES project initiatives. 

A SIPOC document captures the following aspects of the business process scenario:

S = Process suppliers

I = Process inputs

P = The process steps / details

O = Process outputs

C = Process consumers

 

It's important that SIPOCs be hierarchical in nature, and support drill-down into more specific activities.  The highest-level SIPOC in a manufacturing facility represents the overall conversion of raw materials as input to finished goods as output.  Various sub-processes needed to facilitate this, such as scheduling, raw material receiving, quality control, warehousing, etc. all derive from this highest-level SIPOC in some manner.  SIPOCs must also be able to be chained together, as the outputs of a given SIPOC are often inputs to another.  We have built standard MS PowerPoint based templates that ease initial SIPOC layout, ensuring these are defined in a consistent manner regardless of customer.  

Our customers have been very receptive to the SIPOC documentation methodology.  Non-technical stakeholders easily understand how the MES fits into the overall processes within the enterprise, and interactions between the MES and people / external systems, without having to review lengthy technical interface specifications.  They can also easily review the documents with their wider teams.  If a change or correction needs to be made, the SIPOC diagrams are more easily edited than a lengthy Word document. 

Technical stakeholders have a better understanding of the various interfaces that will be required to support process input and output communication, serving as a basis for more detailed interface definitions, swim lane diagrams, architecture diagrams, and other technical collateral. 

Our customers are engaged and eager to work with us to define and review these important deliverables.  This eagerness up front translates to a far more successful overall project engagement, with the customer ultimately receiving a solution that better delivers upon the goals of the initiative, while also adhering to time and budgetary constraints.