AS IS vs TO BE – Conceptual Modelling

One element that I truly have a passion for as part of Product Management is Conceptual Modelling – delving right into the business process, understanding the current AS IS model only to be able to better understand the customers business challenges and therefore appreciating their frustrations and fears.

Once the challenges are identified and understood, we take it a step further, whereby a TO BE process is also explored, defined and even prototyped, ensuring that we are on the right course in achieving a business case, in achieving the business efficiencies we are after – which may vary.

For example, one objective may be to reduce the manual input being experienced throughout the process, therefore reducing resource and delivery time (and cost) required to achieve an outcome. Another example may purely be to improve quality, which may at times mean increasing the process time yet would drastically improve (reduce) implementation and support time – being able to utilise your resources more efficiently and delivering more implementations in the same time. The list can go on, and will differ from company to company depending on their ultimate goal, depending on their business challenges.

Setting the Scene

In my opinion, the journey in achieving the above is simply amazing, even more so if all stakeholders around the table clearly understand the challenges and have a vision for a better solution in solving their business challenges, reaping business efficincies.

Conceptual modelling is not about technology, nor is it about user interface or user experience; that comes later; conceptual modelling is about bringing people together to discuss detail, whereby everyone is EQUAL (no roles or hierarchies) and nothing is ever PERSONAL. Respect and Care for one another are 2 core workshop rules when conducting such an exercise. It may be very easy to get into a blaming situation whereby you may hear someone mention “..yeah, well its x’s fault that we are slow to produce the delivery or the numbers..” and so on. This is the main challenge of any feasibility study exercise and would typically be experienced in the first 2–3 workshops – which is normal. Although, as professionals, it is imperative to portray (and really mean it) that we are one team, that there is no us and them. The fundamental reality is that we have a variety of business challenges as a team, and not as departments or individuals. Thus, put down your ego, put down your pride, respect each other, acknowledge the issues professionally and move on.

Achieving the above shall simply mean that your boat has reached the open ocean with its sails up high, having all hands on deck, respecting and caring for each other, whereby no storm can discourage or dishearten anyone of you.

Step 1: High-Level Process

In the first workshop, the objective is to ensure that all lead stakeholders understand and agree on the high-level process from start to finish (if at all possible, if not, break down the processes). Typically, this wont be the case, therefore already achieving value within the first few hours of the first workshop since all lead stakeholders are now clearly understanding and agreeing (or simply having to accept) on the current process.

Achieving a consensus on the above shall enable everyone to understand and appreciate the challenges across the journey, bringing the team together as one, owning and being responsible for the overall process.

Step 2: Who are the Actors?

Now that everyone understands the process, we must move on in better understanding who forms part of that process, when they come in, what do they do and how do they do it. Basically, who are the people or the type of users (the actors) that perform such actions at any moment within the process?

At this stage, I would typically draw up and define Use Case diagrams – simple diagrams that define a user type and their contribution in and to that process, ensuring that all the input pertaining to their side of the process is drawn up and defined.

Once all use cases have been defined, and nothing has been left out, all stakeholders would collectively understand what everyone at any moment in time is performing, how its being performed and why they are doing it. Such results shall (if done properly) also highlight any duplication or unnecessary tasks being performed which could easily be fixed TODAY (using no technology or change) by simple communication and clarity.

As you can see, we are already in a position to highlight and discuss improvements (quick wins) even in the current AS IS Model – which shall surely feature and provide value in the eventually TO BE Model.

Step 3: Define the challenges

Unfortunately many people start such workshops by simply discussing challenges (therefore jumping right into this step) although is at its fundamentals a waste of time and a ‘selfish’ driven exercise since everyone would simply be talking about their patch, not even being able to begin appreciating or understanding other areas, which if solved may even solve or contribute to their success.

Therefore, having clarity and a common understanding on step 1 and step 2 shall (again, if done properly) make this step much simpler as the writing would really and literally be on the wall. We know the process, we know the who, what, and how that forms part of that process, therefore aiding all lead stakeholders clearly identify their challenges across the board.

Once the challenges are identified, the 1 million dollar question; is the original main objective (pre step 1) still the main challenge and business problem we face? It may have seemed like the culprit 2–3 workshops ago, although now, having a clear list of challenges, defined current processes; after analysing the detail, the result may take us all in a completely separate set of business challenges AND OPPORTUNITIES – which is an amazing place to be in – so congratulate yourselves!

Step 4: Define the TO BE

Achieving step 3 shall no doubt paint a much better picture, a common and more CLEAR vision of where we are going, where we must be and what we are after to solve – having clarity on WHAT DOES SUCCESS LOOK LIKE?

This is where potentially processes and technology start to mingle, prototyping what may be done, how it may be done and why exploring such a scenario shall impact our business process in a much more efficient manner.

These are another set of workshops whereby you keep narrowing down as much as possible the different scenarios throughout the process, building a business requirements document as you progress, and if possible (something I strongly suggest) build proper mockup screens that shall support the desired business process, enabling all stakeholders from across the company understand the challenges, the vision and the method on the how such a process shall be improved.

It will not be the end result, yet it would provide something tangible to the team, something to witness, view and ultimately look forward to. Prototype at this stage; fail, change and adapt now, since failing now is actually learning and refining further!

Find out more on http://www.theproductjournal.io