Introduction
A process diagram should provide employees with a bird’s-eye view of the
most important steps needed to perform the process it describes. To be
useful, the diagram needs to be succinct, complete, accurate and descriptive
enough. Unfortunately, one needs to compromise to address all these
requirements. Moreover, there are further challenges, like where to set
boundaries between activities and subprocesses, or how much information to
provide.
Dynamics 365 used to come with a set of standardized process descriptions
and diagrams, at least the support for the latter being interrupted. They
were useful as overviews, however sometimes they seemed to raise more
questions than to clarify. On the other hand, organizations implement only a
subset from the functionality available, and thus the process diagrams can
vary between organizations. In theory, the implementer or other service
providers could help with a standardized set of process diagrams designed
for specific industries, though this may involve further challenges.
Therefore, organizations might be forced to start from scratch. Even then,
the results might not fulfill the expectations. At least in what process
diagrams concern, there seem to be a huge gap between theory and practice.
Knowledge representation in its various forms, and the process diagrams are
included, can be considered as an art or require more expertise and skills
than usual.
Ideally, organizations should have process diagrams for all
business-critical processes. A more relaxed approach could focus only on the
important processes that need to be performed occasionally, and for which
refreshments are necessary. In this category belongs the creation of master
data, the creation of Products being maybe the most complex one.
The ‘Create Product’ process was chosen to exemplify how a process diagram could be constructed and explain design choices and further aspects. (Click on the diagram to see the full-size version!)
As can be seen, the diagram starts with two subprocesses often omitted, even if they are quintessential for making sure that the next steps can be executed efficiently. The differentiation between activities and subprocesses was made based on the complexity of the steps and the responsibilities involved. When multiple steps need to be performed by other personas, then this might be a sign that a process or subprocess is involved. When other personas are involved, the blocks have different colors.
Another important aspect is the use of succinct descriptions for each step.
The building blocks of the diagrams should be in theory enough, though
that’s seldom the case. To fill the gap the employee needs to navigate
between the blocks and descriptions, which is usually inefficient. Process
management applications provide a better UI, though contents’ navigability
can be challenging as well.
Even if the diagram attempts to generalize a Product’s creation, seldom
performed activities were left out and can be added after the same model.
Optional steps are marked by a decision block reflecting thus the questions
a persona needs to answer. They could be left out.
At least in D365 the data can be imported over the Data Management
Framework and/or the Excel add-in. Some steps can then be consolidated or
split depending on which data entities are used, though the variations in
process are small. Ideally, there should be a description of the respective
steps (e.g., what data entity applies for each step).
The process doesn’t consider the use of an approval workflow, respectively
the newest features.
One might argue that the diagram doesn’t respect maybe some of the
conventions existing in Process Management. Some conventions make sense,
though also in this area one needs to compromise sometimes.
In what follows are given arguments why the various steps were considered.
Approve Product datasheet
The data needed to create a Product usually comes from several departments (e.g. Sales, Procurement, Inventory Management, Engineering, etc.). Therefore, as for other master data, it’s recommended to have a Product datasheet in which the most important attributes about a product are tracked at the various levels of detail that apply.
This approach is supposed to fill the gap in the process in which the
creation of a product needs to be approved (e.g. somebody needs to confirm
that there’s an entitled reason) to eliminate the unnecessary creation of
products (incl. duplicates). Also, there are attributes like Name,
Description, Unit of Measure or Prices that need further agreement.
Moreover, in this way a single persona is responsible for process’
execution, and the approach requires more coordination upfront than within
the process. (It’s easier to have a call with all stakeholders to complete
the list than trying to involve them in the middle of the process.)
The datasheet should also contain the attributes that might require
system’s extension with further setup, and the new values should be marked
as such.
Ideally, the datasheet should reflect the data structure of the entities
needed by the import mechanism or allow easy conversions to them.
Setup System
Setup changes may reach deep inside several modules, requiring further
permissions. Given the sensitive nature of the changes, it’s better for
these changes to be performed by the people responsible for the respective
areas.
Some changes, including the hypothetical ones, might also require further
tests. Therefore, this part of the process should be triggered early enough
so the delays are kept to a minimum.
System’s setup should be ideally documented (e.g. via golden configuration)
together with the policies that apply.
Create Product(s)
The Product datasheet will serve as basis for creating the Products during
the current and the following steps. The data entry should be just a
replication of the data from datasheet without further transformations,
which tend to increase the chances for mistakes.
Supposing that D365 is the master system, which usually should be the case,
the products can also be created then in third-party systems once the
Product number is available, systems in which further restrictions, policies
and value mappings may apply.
Ideally, there should be an automatic interface responsible for data
synchronization, otherwise manual effort is involved.
Add language specific names/descriptions
Maintaining both, a Product’s name and descriptions in the various
supported languages should be mandatory. The attributes should reflect the
level of specificity required.
Assign Product dimensions
The Product sheet should reflect whether the Product requires dimensions,
and which are the respective values, respectively the combinations allowed.
Maintain Product categories
Categories’ maintenance is usually performed by other roles and belongs in
the Setup System process. This step includes the assignment of Products to a
category, respectively the maintenance of further attributes like Main
account or Item sales tax group.
Release Product(s)
The product(s) available in the datasheet are released to the Legal
entities in scope. This just makes the Products available for further
maintenance.
Update Released product(s)
The Product datasheet is used as basis for entering the Legal
entity-specific attributes.
Update Default order settings
This step requires updating the attributes that deviate from defaults (e.g.
Default Site, Stopped, etc.).
Maintain Product ext. Descriptions
Product external information might be needed for Customers and Vendors to
which the Products are sold, respectively from which are purchased. The
entries are needed for each Product dimension that applies.
Maintain Trade agreements
Trade agreements allow transparency of the Sales and Procurement prices
that apply for a time interval, specific group or other characteristics.
Therefore, they should be used when possible.
Maintain Bar codes
Bar codes apply usually for inventory-based products. Multiple bar code
types may apply.
Validate Product master data
This step involves a review of the master data just entered, though it can
involve an interface to the ‘Monitor Master data’ process, when such a
process was defined as part of the Data Management or Governance initiative.
The interfaced process could be triggered as part of the initial process or
as part of regular checks, especially when the policies changed.
Typically, the validation of the Product master data should be done by
other persona after the four-eyes principle.
Having a set of reports with all attributes in scope (aka ‘Product master data reports’) can easily pinpoint where the gaps are. Moreover, the ‘Product master data policies’ could be built within these reports however this is a long shot. If the policies are known, a simple review should be enough.
Correct Product data
Besides troubleshooting, this step involves reviewing several or all the steps performed before and taking the necessary actions. Ideally, should be available a list of the most frequently met scenarios, respectively of fixes and workarounds.
Previous post <<||>> Next post
No comments:
Post a Comment