Retailer to supplier, order to delivery. Anything wrong with this?

Sorry, the title is a little misleading, there is nothing wrong with that workflow as such, but in the real world the actual workflow is not that simple. Add to the situation the number of suppliers a retailer orders from, add to it the management of their own EPOS system and stock, throw in a pinch of time management and you can see a number of problems cropping up…

Our workFile EPOS software has been around for a while now, and a number of stores are using it very efficiently, with it streamlining many business processes and ensuring day to day activities are completed and not missed. Not trying to sell my own product here, but its a great EPOS solution…However, one of my biggest frustrations with the solution (especially in particular industries) is that suppliers don’t make it easy for stores to purchase from them. The workflow from a retail managers point of view is not great, and to top it off, it isnt great at the suppliers end either…

The problem

A store needs to place an order with a supplier, typically because stock has been sold or they are looking at new items to keep in stock. Great, our workFile EPOS software auto generates orders based on some complex rules, I digress, needless to say the store knows what it wants to order. However, what does the manager have to do then? Ideally, press a button and be done, but that’s not the case. Typically they then have to call through to their representative, indulge in a nice chat, talk them through every single order (which in some cases can be hundreds of different stock lines), hope that nothing has gone wrong, hang up and then wait for delivery…So, something the stock system has done in a single minute, has now taken up almost an hour (obviously depends on the size of your order) or more.

Many suppliers do now see this as an issue, and offer email order generation. This means the manager can create an email and send that (again our workFile EPOS software will do this for them quickly and easily). However, are suppliers missing the point? It now means someone else at their end still has to do a lot of hard work, though true, life for the retailer is that little easier. But there are still issues here. The retailer would love to know the actual status of the order, expected shipping date, when it has been shipped etc. A simple email offers no benefit to the retailer other than some time saving. In many cases, it may even mean special offers are missed…

Using websites is the next step, with many now providing ordering screens through their website. Again though this can be time consuming for the retailer, especially if they use the website in the same eCommerce fashion the general public uses websites. However, those special offers will be visible (you would hope). Suppliers need to think how their retailers actually work, be it via eMail, phone, web or even better through EPOS….In addition, our problem at the supplier end is still there….

The solution

Well I don’t want to give too much away as my company already has a solution in place and is currently trying to push this into specific markets. However, needless to say, the solution involves fewer steps and a far greater level of system wide integration between retailer and supplier. It also involves cleaning up the process not just at the retailer end, but the suppliers end. As a specialist in Business Process Management, you can see my frustration at how “broken” the workflow is between retailer and supplier in many industries…

There is one thing though that we all have to remember. A client of ours hit the nail on the head when he said “Suppliers act like petrol stations, they don’t want you to be able to get your fuel and pay without coming in and seeing all the other things they sell. What they want is to make you come to them, they can talk you into other items to add to your order…After all you don’t sell mars bars at the petrol pump”.  With this in mind, we have to ensure that suppliers still get what they want from a more streamlined workflow process. When a manager has to talk to an agent from a supplier, the supplier can at least highlight new products, special savings, increased discount opportunities etc. So, any new workFlow needs to be able to replicate this in some way. So an improved solution must work, retailer to supplier, but also supplier to retailer…

When this starts to happen I will be a happy man, our workFile EPOS software has been setup and ready for this type of workflow for a number of years now, yet alas, no suppliers are ready to embrace this way of working…Yet…

Intelligent BPM maps

I have posted about BPM maps hindering flexibility and capabilities to some extent before (regarding systems integration). See:

https://andrewonedegree.wordpress.com/2009/11/30/bpm-mapping-tools-integrating-data/

https://andrewonedegree.wordpress.com/2010/01/08/incorporating-automation-into-your-processes/

However, in this post I want to take this further by looking at how BPM maps (I use the term map loosely here) can become intelligent and hold much more than just business process routing rules…

The role of the map

For many this is the “definition” if you like of a business process, shown in a graphical map format. This is great, and it’s true to some extent. However, I believe the primary role of a workflow system is to deliver systems integration, not a predefined diagram of a process.  BPM and workflow only works well when it brings together systems, people and data to maximise the efficiency of a business requirement (or process if you like).

So what is the role of the map? Well it is there to provide business rules for a cross section of applications to deliver a solution that allows users to do their work effectively. (Not easy to read that sentence). This work is shown as a process. For me, I prefer to see processes graphically, but not in my BPM system, well not used to define the rules etc within my BPM solution. Graphical representations are great for identifying the business requirement, and should be done by a BA. But process maps should be used as a “specification” if you like for a developer to build my intelligent process map…

Using a developer to implement my business rules

I know that many of us want to have a nice mapping tool that allows a business analyst (BA) to create and modify maps / business processes. However, in the real world, this means you have a couple of restrictions / issues.

1. You can’t easily integrate with other LOBs and data required for a particular step
2. You can be limited to other business rules / factors (that are outside the scope of your map)
3. Automated steps often require “Robot” type step applications to be written (specifically for your requirement)
4. Much more emphasis is placed on developers for the actual implementation / front end of much of the system (if you require intelligent integration / more complicated system integration)

As mapping tools get more powerful you still have these issues, mainly because a BA is just that, not a technical person who wants or should be bogged down in the technicalities / functions / calculations etc required for the business.

By using a developer to take your map and build business rules into a BPM system (if your BPM architecture allows this type of process definition), you open up a world of systems integration and flexibility. Effectively your business rules / map can now become intelligent.

Intelligent maps

An intelligent map is more than just business processing rules. It contains actual business processing logic, it has the capabilities to bring in data from third party software, carry out complex calculations and functions, raises events and triggers and does all of this within the map itself.

 Most BPM maps cannot provide this level of integration or capabilities to execute / carryout processing functions. Many times these types of functions are provided in the form of “Robot” applications or step processors. These are background applications or services written by developers to include business rules and functionality into the process map, because the map itself cannot support this level of intelligence. The outcome is a solution that requires much more processing power, requires greater input from developers and one that is harder and more costly to maintain.

By shifting emphasis of functions and rules to an intelligent map, you provide a BPM solution that delivers greater out of the box functionality, keeps initial costs far lower and requires less development work / bespoke step processors to be written. In addition, when your business needs to adapt and change, updating processes are far easier and quicker. Since the map itself contains the business rules of your processes (as well as the definition of that process), you need only modify one thing, your intelligent map. There are no background processors that need modification, no new application changes to be made etc. Because the business intelligence is all stored in a singular place…

Quick example…

A good example of a BPM platform that works in this way is workFile BPM. It has been architected to ensure the “map” holds all the business rules as well as having the capabilities to integrate with other LOBs and execute functions, triggers etc within the map. Developers have to build the map in this case, based on information provided by BA’s.  

The out of the box user interface is in most cases the only interface you need, simply because of the intelligence available at the map level. However, there will always be occasions when “bespoke” processors are required, and the workFile BPM platform provides a complete XML Web Service API in which developers can build on the intelligence provided in their maps within workFile BPM…

Conclusion: System integrator or process definer…

I see the main aim of BPM and workflow to raise the efficiency of businesses by making it easier for users, and the business, to complete work. Defining processes allows us to visualise this work, however, the BPM platform brings together everything that is required to complete the work. So a BPM platform should be a systems integrator first and foremost, this is the real beauty of BPM and workflow…

BPM mapping tools – integrating data?

As I was shifting through my usual amount of mails this morning, I spotted a google alert regarding an article titled “BPM must integrate people, documents”. Now I thought that’s a tad obvious, and promptly went to read the article thinking I had missed something….And basically I hadn’t…

A good point was raised though, that most BPM software targets business analysts and project managers. There are usually options to utilise SDKs but these are often a low priority as the main selling point is almost always “out of the box” demonstrations aimed at business analysts. However, am I the only one that sees a flaw in this?

BPM design tools. Are they flawed?

Now putting together demonstrations and targeting analysts are all good things to a degree, however in the world of BPM I still maintain that too much is done to show a great demo, allow analysts to “model” processes and not enough is done to provide real integration and back end flexibility. What do I mean by this? Well, systems integration in the “real world” often require a lot more work than simply setting up some connectors with common integration points. Often you need to call functions from other systems, pull in data from more than just a single source, carry out some complex processing, update multiple systems etc all within a single step. Can you really do all this from a fancy modelling tool….My guess is no.

Modelling tools give power to the business

This is so very true. Business can make tweaks to their processes and make them happen immediately, which is great. Many BPM solutions almost live and die by their modelling tools / facilities and spend vast amounts of time, effort and money in making these better and more flexibile. There are so many benefits which many other articles will and have talked about. But again, in my experience, many larger systems aren’t just “out of the box”, nor are many smaller systems. They have applications written in .NET for example, that use the process map for guidelines and routing business rules. The application itself then contains its own “business layer” (if written well) which contains certain inbuilt business rules – typically regarding calculations and integration with other LOBs.

I have worked on numerous BPM projects that work in this way, providing lots of applications for different steps within the process map, using the process map for merely setting statuses and routing information. The application itself holds all the business logic and integration code. Even on the more complex solutions, an application was delivered in place of any out of the box front end components. Business rules were built into the application to interpret the process map, which in theory did give back more power to the process map, regarding statuses, routing, cooling off periods etc.

In this case you can see that the modelling tool gives power to the business on when and where to route work for example. Even such things as options the user can select, cooling down processes, awaiting other tasks etc. However, the real integration and bringing people / data together, happens in the business application, written by developers specifically for that client requirement.

But what happens if the business analyst wants to make a change to the process that involves carrying out additional calculations at a particular step or pulling in more content / data from other platforms. He can make the changes as he sees fit in the map, but what about the actual rules etc? More often than not a “change request” is raised and someone in the development team has to make a modification to the code of the application, which then obviously needs to be tested in a model office environment before being released. So even though the business feels like it has ownership of the process map, it doesn’t really have great ownership over how the map actually works as a process for the business. In this scenario the actual time taken to make the change is quite lengthy. Let’s break it down:

1. Business identifies the need for change
2. Business analyst is involved and investigates the options
3. Business analyst provides a new solution
4. Business analyst updates / creates a new business process map
5. Change request is made and passed on to the software developer
6. Business analyst updates the process map
7. Software developer makes the required changes
8. Process map is then tested (UNIT test)
9. Software is then tested against the new map (UNIT test)
10. Software is then sent back to a testing environment
11. Testing environment tests the new map and all the related applications / scenarios
12. New process map and application is released to the live environment

As you can see that’s quite a list of things that must happen.

What’s the answer?

It’s simple. Let’s let people do the jobs they are supposed to do, and let’s let software provide us with what it is designed to do, nothing more and nothing less.

So with this in mind. imagine a business analyst who models the business process. He / she put together a complete map with users, groups, security, calculations identified, function calls to other LOBs etc. They then model this in Visio for example with some accompanying documentation.

Once this is all complete, let’s move this over to the actual BPM software, which should allow all these things to be included into the “map”, even execution of complex code, calculations and integration etc. Please note, the BPM engine shouldn’t be confused with the BPM front end at this stage. The user will never see the “engine” as such. So our BPM specialist (which is more than likely at this level to be a developer), makes the changes to the BPM map, codes the required calculations and integrations and completes the map. This is then “tested” before being published. Please note, no application code has changed, there is no need to test the applications etc, rather just the map itself.

The last part of our solution is our front end. This should be written to only present data to the user and allow them to interact with that data, people or other systems depending on the BPM map (which holds all the rules / calculations etc). Because map changes are made in the map and are completely separate from other deliverable code, namely our actual application / front end, the whole process of making a change to the process map and having it made live is far shorter, less likely to fail, far more flexible and in the end, much cheaper.

Let’s review:

1. Business identifies the need for change
2. Business analyst is involved and investigates the options
3. Business analyst provides a new solution
4. Software developer updates / provides a new map
5. Process map is then tested (UNIT)
6. Process map is sent to testing environment
7. Process map is made live

We could even add in: 8. Full testing of the process map and application; and we are still 4 points shorter in our list of things to do. In addition, each point in this second implementation is not as time consuming as those in the previous list…

The downside

Because this type of BPM system / solution doesn’t display a great map for business analysts with lots of feature rich BA tools, it doesn’t really quickly and easily demonstrate BPM. A system like this won’t allow a BA to make a change to the process map and have it published immediately. All of this means that this kind of system, though in many ways far superior, may be viewed in a demonstration as a simpler tool with fewer capabilities.

Conclusion

When choosing your BPM platform, really focus on your actual requirements. Have more than just a rough idea of your processes and desired outcomes. If you have an in-house IT department, make sure you bring along a senior member of that team to any demonstrations / meetings.

Remember, a demonstration is not the same as a solution and don’t fall for the statement, “we have an SDK you can use to integrate”. This almost always means you need to build those more “complex rules and calculations” into your own application / step processor, not in the process itself.

BPM mapping tools are great; they deliver a powerful and rich environment that is fantastic for demonstrations. But make sure the BPM map itself has the capabilities and flexibility to meet your requirements without the need for you to build essentially what should be process rules into your own step processor / front end application…

Even with BPM there is still a process that you must follow to get your BPM system to work for your needs…