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
