kurthatlevik: Retail process modeling; Divide and conquer
I normally don’t share much that is considered as employer specific IP/tools, but today I will do an exception. At EG we have for years been focusing on how to address the business processes for the Retail industry, and how to name and classify these processes. By combining the structure APQC business process mapping and classification with the essential understanding on how to improve and implement the retail business processes. This means we have a that a predefined approach for scoping and planning retail implementations. The key to this model, is to ensure that we can have a good scoping and planning phased retail implementations based on the customers actual processes.
The top level in the EG Retail model we group all epic processes into “Management processes“, Operating processes” and “Support processes” as seen in the following picture. Then we have broken each process into sub-processes(Levels), pretty much according to APQC.
Level 1 – Operating processes
The Operating processes are the day-to-day processes taking place in at a retailer. We have divided the level 2 processes into 5 specific areas as seen in the figure below.
1. Category management is all about grouping products into hierarchies with similar properties and attributes. This makes it possible to give responsibilities and parameters on group levels, instead of on SKU level.
2. Sourcing and procurement is about making sure that we have the products available on the store/channels available for sale. This means working with vendors and producers, and to have clear planning strategies.
3. Retail logistics is processes that typical happens at the central warehouse, and when replenishment to stores is needed, then it is sent at the right time.
4. Omni channels is about being available to customers on multiple platforms and through the customers purchase experience. It stretches from brand awareness, store, web, mobile, loyalty and after sales processes.
5. Store operations is what is happening at the physical store.
Each of these level 1 the retail processes have been split into the following level 2 processes. In the column 1 we have the parent process, and below we have the sub-processes in the horizontal boxes.
We can further look deeper into the category management processes and we see the following level 3 sub processes. You can see the red boxes in the level 1, have been moved to the first column in level 2, and then the sub-processes are shown in the horizontal columns.
For each and every retail process we break the processes down to level 3 or level 4, and we then also decide on how we are solving each of these sub processes. This is done by color coding the processes. As you can see in the following picture, you see that most is solved in standard Dynamics 365, but also with some 3-party products. There are also processes that is not covered by the solution stack available currently.
At level 3 we have mapped each of these processes into APQC and into the LCS business process modeler. When we take the level 3 process called “Define categories” we have a relevant APQC process named 2.1.1, and this means that we(or APQC Members) can extract som KPI’s to allow us to define how this process are performing.
Together with APQC we can use these KPI’s to measure how good this process if performing, and also compare the process with similar retailers also using the same KPI’s. This tells us if the process needs to be improved to achieve more.
Microsoft released a new APQC library in November 2016, that is available in LCS, and here Microsoft have defined 3774 business processes and have 617 flow charts for Microsoft Dynamics 365 for Operations. This gives us a further ability to map the processes directly into Dynamics 365. Here I have searched for “category” to see what APQC and Dynamics 365 processes are supported.
Using the process mapping to create a implementation plan.
When we are working with our customers, we build a scope plan quickly, and define what processes we what to start with, and what to postpone into future projects. We can be clear about the how quickly the ROI can be, and that we can start on business processes where we today have low performing processes. In the sample scoping below, I show how we can start with the stores, then in project 2 enable the HQ suppy chain/replenishment and then finally start a project where logistics to the stores are in scope.
This means we can do project phased retail implementations within the budgets for the retailer. Each of the “Boxes” also contains process descriptions, VSTS backlog and task lists, UAT test scripts and workshop agenda’s. This means that when running a retail project, we don’t have to start with a blank whiteboard.
In addition the model have been mapped into Visual Studio Team Services. This means that the Retail model is also a implementation model for than can be used by project managers, consultants, developers, customer super users and stakeholders.
I hope this gives you some ideas on how we are approaching the retail market from a business process standpoint, and delivering our implementation as predefined repeatable services where Azure, Office365, LCS, VSTS, ODM and all the other good Microsoft services are used to the full extent.
Retail is detail, and the future is bright J
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|Опции темы||Поиск в этой теме|