Change Management user manual

Welcome to the user guide of the Change Management app. The application implements the change management procedures defined by the IATF (International Automotive Task Force) in digital form, following the principles of 6M — offering a modern, environmentally friendly alternative to traditional paper-based solutions.

Digital document management has many advantages over paper-based systems:

• Accessibility and convenience — Digital documents can be accessed from anywhere at any time over an internet connection, giving immediate access to the information needed.
• Environmental protection — Paper-based documentation carries a significant environmental burden through printing and paper use; the digital solution reduces it.
• Security and data protection — Digital documents are easier to protect against unauthorised access, and backup and recovery are simpler too.
• Simplified process management — Tracking, approving and documenting changes is more transparent, which reduces the scope for human error.
• Scalability and flexibility — The system is easy to extend and adapts to the growing needs of the company.

The guide shows in detail how to take advantage of everything the app offers.

The diagram below illustrates the operating mechanism of the app — let us start by reviewing it.

The first step is to complete the settings the app needs. This data drives the app and is essential for correct operation. The setup steps are as follows:

1. Defining areas — The areas within the company where change management is to be applied.
2. Defining departments — The departments to be involved in change management.
3. Defining users — Who has decision-making and administrative rights, and who makes the final decision. Only one user per area may hold final decision-making authority.
4. Defining internal tasks — The tasks that are not included in those defined by the 6M matrix but are necessary to implement the change.
5. Building the change categories — Every possible change has to be assigned to a category. The tasks defined by APQP can then be mapped to these categories.
6. Defining the 6M matrix — Mapping which actions have to be carried out to implement each change category.

The system handles seven document states depending on how far the document has progressed. Six of them appear on the diagram; the seventh is the "closed" state.

When a new document is started, the type of change, its scope, the area affected and the change category must be defined. The system generates the task lists and decision lists from the settings. The internal decision process list is built from the user setup table — whoever is assigned there to the area in question can make a decision. The 6M matrix action task list is built from the 6M actions table, and the internal task list from the internal tasks table.

Once the requester has filled in the basic data and defined the subject of the change, the decision process can be started. The steps of the process are:

1. Completing the internal decision process.
2. Carrying out the tasks defined by the 6M matrix and uploading the evidence.
3. Verifying the tasks defined by the 6M matrix.
4. Sending the customer approval request, if required.
5. Carrying out the tasks defined in the internal task list.
6. After this the document goes live, that is, into active status.
7. Once rolled out, only the PDCA check remains: this is where the effectiveness of the implemented change is verified.

The app is best installed by a user who works with change management and will administer the app. During the first installation the installer automatically performs the following:

• Registers the installing user among the users, as administrator.
• Creates the number series named CHGM for numbering the documents.
• Sets this number series as the document number series.
• Sets the maximum validity of temporary documents to 90 days.
• Adds the task that runs the codeunit for the scheduled jobs to the job queue entries.

General setup

Apart from the IATF catalogue number, the system sets these during installation; they can be changed here. The IATF catalogue number has to be entered by you.

Switching off the "enable internal mailing" toggle disables notification e-mails. This setting does not apply to approval requests sent to the customer: those must always go out from the app, because the system has to manage background settings and needs to know whether the request has been sent.

The "temporary document validity" field controls the expiry of temporary documents, given in days. The "PDCA check duration" is the period within which the effectiveness of the implemented change has to be verified — the system calculates the deadline from the date formula entered here, at the moment the document moves to active status.

Automated task execution

With "send approval request automatically" switched on, the system sends the notification about the change to the customer by itself. With it switched off, the request can be sent from a menu item. The e-mail addresses the change request should go to are set at the bottom of the customer card.

With "close temporary documents automatically" switched on, the system closes expired temporary change requests by itself. With "send notification about expired temporary documents" switched on, every user registered in the change management user setup receives a notice every Monday morning — provided there is an expired temporary document. This schedule can be changed in the job queue entries.

Business Central URL

The system appends the link set here to the notification e-mails.

E-mail settings — customer approval request

This is where the subject and body of the e-mail notifying the customer about the change are set. It is worth reviewing this and adjusting the line breaks.

The attachment settings control which uploaded documents go out with the change notification. The PCN and the waiver are always sent, since those are what the customer has to be notified with. Switching on "send change request document" also sends the change request document itself — the one produced by the Reports → Print document menu.

E-mail settings — internal mailing

This section configures the subject and text of the system's internal e-mails. After installation it is worth adjusting the line breaks here too.

Substituting document data into e-mails

Individual document fields can be substituted into the text of the e-mails: if you use the expression %n in the "mail body" section, where n is a whole number between 1 and 9, the following data is inserted:

• %1 — Document number
• %2 — Name of the requester
• %3 — Link to the BC sign-in page
• %4 — Area
• %5 — Identifier
• %6 — Work centre group
• %7 — Validity, for a temporary document
• %8 — Production order number
• %9 — Customer name

Area setup

Used to define the production units — for example assembly line, paint shop, machining shop. The area code may be at most 10 characters, the description 50.

Department setup

Used to define the organisational units — for example production, product engineering, process engineering, maintenance. The department code may be at most 10 characters and may contain letters only; the description may be 50 characters.

User setup

Used to define the users who have decision-making and/or administrative rights.

The users who will have decision-making rights must be defined here, together with the manager — one per area — who will be the final decision maker. The app is structured so that everyone listed here has to make a decision on the document per area; this is the basis of the internal decision list.

A substitute user has to be set up for everyone; the substitute is entitled to decide on behalf of the user they replace. The users' e-mail addresses must also be entered, because this is where the system's notification e-mails will go.

If the user has decision-making rights, tick the "decision maker" check box; if they have final decision-making authority, tick the "final decision maker" box. Administrative rights go with the "6M matrix administrator" box — this permission allows editing the settings, the task lists and the 6M matrix. A user can be removed with the delete button.

Defining internal tasks

This is where to define the tasks that are not among those defined by the 6M matrix but are necessary for the document to reach active status — for example updating the production orders when a material or an operation changes. These tasks have to be carried out by the person responsible after the customer's acceptance arrives. Tasks are grouped by area and department; they appear in the last part of the change request sheet, and are only available once customer approval has been obtained or is not required.

The task itself is worded in the "task description" section, along with the area it belongs to, the responsible department and the person assigned to complete it. A date formula can be entered in the "task duration" section, which determines the deadline for the task.

KPI registration

This is where to record the KPIs used to verify the effectiveness of the change after it has been implemented.

Since setting up the application can take a long time, demo data can be inserted with the "generate demo data" button. This creates a few change categories, departments, areas and matrix actions. The function is only available in the demo version of the app.

The delete data function removes all records from the following tables — also available in the demo version only:

• Change requests
• Internal task lists
• Decision list
• Matrix action list
• PDCA action list

The licence key can be imported under the "licence" section of the settings. The key is a text file with a .lic extension that identifies the subscribed period.

After installation the app runs in demo mode: at most 50 change requests can be created with it, with no time limit. Live use requires a subscription, under which nothing is restricted.

If the subscription expires and the app is not reactivated, the documents created so far remain editable and readable — a process already under way can be finished — but new requests can only be started once the subscription has been renewed.

A subscription requires a software supply agreement with the distributor, setting out the terms of use. To have the key generated, the app's appID must be provided; it can be found under the "licence" section of the settings (red frame in the image below).

The following has to be done after installation:

• The app's job queue entry has to be started, otherwise the automated tasks will not run.
• Check that Business Central is configured to send e-mails.

Checking the job queue entries

Type "job queue entries" into the BC search box, then open the job queue.

Something like this should appear:

Check that the entry named "change request task scheduler" is in "ready" status. If it is not, open the card and press the restart button in the menu at the top.

This task runs every day at 6 a.m., checks whether there are any expired temporary documents in the system, and acts according to the settings discussed above.

Checking the mail settings

If sending mail from the app is enabled, an e-mail account has to be configured in Business Central. You can check this by typing "email accounts" into the search box. If nothing is set up on that page, ask your system administrator for help.

After installation, type "change management" into the search box. Two results appear; the list view is the one you need. It is worth bookmarking — no other page names need to be remembered, because every function is reachable from here through the app's menu system.

The list view shows the basic data of the documents created. Clicking the document number opens the document. The buttons framed in red filter on document status. The "actions" menu (green frame) offers the following groups:

• 6M matrix — functions relating to the 6M matrix and the change categories.
• Tools — the app setup is reachable from here.
• Reports — document printing and statistics.

The "new" button creates a new document, and the delete button removes one — with the appropriate permission (purple frame).

Open the 6M matrix from the menu below.

A change category can be entered by clicking the "add new category" button.

Since a change request can be permanent or temporary, it is worth recording the change category for both types. It pays to build the category code to some logic: in the image below, for instance, the first three characters represent the scope of the change, followed by the abbreviation of the category itself (MAT = material scope, SUPPCH = supplier change → MATSUPPCH). A given category code has to be entered for every area.

Once the category codes exist, they have to be imported into the 6M matrix so that tasks can be assigned to them. Close the category page and press the "import categories" button on the matrix page (red frame in the image below).

After the import you should get a list like the one above, except that no actions are assigned to any change category yet. The next step is to assign the necessary actions to each category by ticking the appropriate check boxes. In the "duration of all tasks" column, enter a date formula for how long all the tasks should take to complete — the system uses this value when calculating the deadline.

To change the categories, use the "add category" button. After making the changes, close the categories window and use the "synchronise categories" button on the matrix main page (green frame). This synchronises everything with the category database and does not delete existing data.

Once the appropriate actions have been assigned to every category, the system is ready to use. The next chapter shows how it works through an example.

A new document is created with the "new" button in the app's list view. The page can be divided into nine parts.

• Basic data — the basic data of the change request document.
• Current regulation — the description of the existing regulation we want to change.
• Description of the proposed change
• Cost impact — the estimated cost of the change.
• Internal decision — the users who belong to the given area and hold decision-making authority.
• Info panel — information about the document.
• Actions based on the 6M matrix — the tasks assigned to the change category on the 6M matrix.
• Internal task list — the tasks that are not in the 6M matrix but are necessary to carry out the change.
• PDCA check list — the KPI list defined in the settings, used to verify the effectiveness of the implemented change.

Start a new document by filling in the basic data. The system assigns the document number automatically — you only need to leave the field. The "status" field is not editable: the system manages it according to how far the document has progressed.

The type of change can be temporary or permanent. For a temporary change the duration has to be given, and it may be at most as many days as set in the settings. The "area" is the code of the unit the change request relates to — this is the basis on which the internal decision list is assembled. The "category code" determines which category the change belongs to; this is the basis of the task list under "actions based on the 6M matrix". The "scope", "requester" and "created" fields are managed by the system; the value of scope depends on the category code entered.

The decision and task lists are built once the "area" and "category code" fields are left, and their content depends on those values. If the change is item specific, the "item number" can be entered; if it affects a production order, its number goes in the "production order" field. The "description" field takes any comment, and the "work centre group" field the number of the group affected.

The "customer name" is mandatory if the change requires customer approval — that is, if a waiver or PCN is ticked for the given category in the 6M matrix. The "customer item number" is looked up automatically once our own item number is entered. Of the basic data, the following are mandatory:

• Area
• Change category
• Customer name, if the change requires customer approval (if it is missing but required, the system warns you).

If no contact mailing address is set on the customer card, a warning appears in the top left of the screen, from where the customer card can be opened with the "run customer card" link and the e-mail address set conveniently.

Once the basic data is in place, the descriptions of the change and the cost impact have to be entered. The cost impact shows the additional cost or the cost saving of the change per unit of product: a negative number means a saving, a positive one an additional cost.

In the example above we created a document recording the replacement of the supplier of a raw material. The decision and task lists are already in place and the content of the info panel has changed too. The document is still in "preparation" state: the decision process has to be started by whoever created it. Before we do that, let us look at the info panel on the right.

The info panel reports on the state of the document and tries to summarise everything related to it. Below the document number it shows the completion percentage, the number of tasks to be done and already finished, the area affected and the name of the change category. It also reveals the state of the document, whether customer approval is needed and if so whether it has been sent, whether the internal notifications have gone out, who the final decision maker was, what they decided and when.

Information about the uploaded attachments is shown as well. These are the specifications, measurement results and test reports assigned to the change category in the 6M matrix. In our example six documents have to be uploaded: a DFMEA, a control plan, a packaging specification, the trial production report, an appearance approval report and finally the PCN. Once uploaded, the "no attached document" text is replaced by the file name, and clicking it in the info panel downloads it.

If the customer has replied, their response has to be uploaded too; at upload you can state whether the request was accepted. If it was not, the document moves to "closed" state; if it was, the process can continue. At the bottom of the panel there are four tiles that open the task lists — they show the tasks not yet completed, and everyone sees only their own. The numbers on the tiles show the given user's open tasks.

Let us continue processing the document by starting the approval process with the button above (the F2 shortcut also works). The process may take a moment, because this is when the system sends the internal notification e-mails, if they are enabled.

Once approval has been started, the header, the descriptions of the change and the cost impact are no longer editable. The system reports the end of the start-up with a message, the document status changes to "under approval", and the internal approval list becomes editable for those with decision-making rights.

The next step is to take the document through the internal decision chain: every department within the given area has to make its own decision.

The list shows who is entitled to decide and who the substitutes are — only they can change the decision. The row highlighted in red belongs to the final decision maker, who decides once every department has made its own. If the final decision maker rejects the document, it moves to "closed" state.

Once the internal decision list is complete, the 6M matrix task list becomes available. The decision can also be edited on a card page if that is more convenient: click the "entry number" to get there.

When every department has made its decision, the system sends an internal notification e-mail to the final decision maker. The fully completed list looks like this:

The 6M matrix action list becomes available after the final decision. Note that the deadlines are still empty when the document is created: the system calculates them at the moment the list becomes available on the document.

Before we continue, let us glance at the info panel.

The next step is to produce the tasks and documents of the matrix action list. These have to be uploaded under the "attachment actions" menu group. Only the menu items relevant to the document are active — if, for example, no drawing change is prescribed, the drawing upload menu is inactive. After uploading, the info panel shows what is already there and what is not.

The system will not allow a task to be set to done until the corresponding document has been uploaded. There are, however, tasks that need no document:

• Bill of materials change
• Routing change
• New item registration

Opening the links downloads the documents. The one shown in red is the document that must be submitted for customer acceptance. The 6M matrix action list then looks like this:

The next point is verifying the completed tasks. Anyone registered as a decision maker for the area may verify — but nobody may verify their own task. Verification is recorded by ticking the check box in the "action verified" column. If the verifier does not accept the completed task, they have to enter the reason in the "verifier comment" column and reject it with the "reject action" item in the drop-down menu on the left.

In that case the person responsible has to redo the task concerned. A rejected task is shown in the image below.

Once every task has been verified, the approval request can be sent to the customer — automatically or by hand from the app. The request is an e-mail the system assembles from the uploaded documents according to the settings. With manual sending, it goes out from the "send approval request to customer" menu. The document then changes to "under customer approval" state and will not move on until the customer's response is uploaded through the "customer decision document" menu. After the upload the system asks for the outcome of the customer decision and sets the document state accordingly.

If the answer is positive, the internal task lists become available; once those responsible complete them, the document moves to active status. If the answer is negative, the document is closed. The completed internal task list looks like this:

This list serves to verify the effectiveness of the implemented change. Whenever a new document is created, the system produces a check list from the KPIs defined in the settings.

While the document is not yet in "active" state, the values of the selected KPIs before the change can be entered in the "old value" field. Not every KPI will be used in every check — unused rows can be deleted, again only before the "active" state. The delete function is in the menu next to the PDCA check list caption.

Once the required KPIs have been selected and the values before the change entered, you should see something like this:

When the document moves to "active" status, the "old value" field is no longer editable, while the "new value", "comment" and "PDCA done" columns become accessible — and this is when the system calculates the deadline. From here on the check can be carried out. When you are done with a row, tick the "PDCA check done" box; the row then becomes read-only. If it is more convenient, you can also work on the card page of the row by clicking the number in the row number field.

Other documents relating to the PDCA check can be uploaded as well: use the "upload document" item in the PDCA group of the "actions" menu. The menu is only available while the document is in "active" status.

Closing a temporary document

This menu item closes expired temporary documents.

Copying a document

A copy can be made of any document with the "document operations" → "copy document" menu. It is useful when several change requests have to be started that differ only slightly. The copied document will be in "prepare" status and is handled the way described above.

Re-importing the internal task list

This menu item re-imports the internal task list.

Re-importing the KPI list

This menu item re-imports the KPI list.

The purpose of the task lists is to let the signed-in user check their outstanding tasks easily. They are available from the info panel of any change request document, and from the following role centres:

• Sales order processing
• Accountant role centre
• Machine operator role centre
• Production planner role centre
• Project manager role centre
• Purchasing manager role centre

The lists show only the open tasks belonging to the signed-in user. The exception is the list of actions to verify: it shows every open verification task, because that is tied not to a user but to a user permission.

The lists are ordered by deadline and use colour coding as well: an overdue task appears in bold red, and one due within a week in bold blue.

• Open actions (responsible) — the open tasks defined in the 6M matrix where the user is the person responsible. Includes items with no deadline.
• Open internal tasks (responsible) — the open internal tasks, including items with no deadline.
• Open actions (substitute) — the open 6M matrix tasks where the user is the substitute.
• Actions to verify — the actions awaiting verification. This list is not filtered by user, because the only condition for verifying is that the user is registered for the area.
• PDCA check list — the unfinished PDCA checks. Only items with a deadline appear.

An item may sometimes have no deadline yet. That is because the system calculates the deadline when the given task list becomes available on the change request — meaning the change request has not reached that state yet. The image below shows such a case.

Task lists on the info panel

The task lists are also reachable through the tiles on the info panel.

Three reports are available under the Reports menu group:

• Print document — the printable version of the change request document.
• Statistics — a report on the change requests for a given period.
• Setup summary — every setting in one place: the tasks entered, the change categories, the areas, the departments and the registered users, each in its own table.