---
title: "Implementation docs kit"
---

# Implementation docs kit

## Project Management Plan (IDK-01)

Template IDK-01, version 1.0. Phase: Initiate Project.

 ## How to use this template

 
- Write it during Initiate Project, before any design workshop is booked. It is the contract between the two project managers on how the project will be run.
- The supplier project manager drafts it. The customer project manager reviews every section and supplies the customer-side names, calendars and constraints.
- Replace every `[bracketed field]`. Delete rows marked `Example:` once you have your own content.
- It is done when the steering group has approved it and each baseline (schedule, cost, solution scope, project scope) carries a version and a date.
- After approval, nothing in sections 3 to 6 changes without the procedure in section 6.4.

 | Field | Value |
| --- | --- |
| Template ID | IDK-01 |
| Phase | Initiate Project |
| Owner | Supplier project manager (with customer project manager support) |
| Approver | Steering group |
| Qualification gate | Project Initiated |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Project summary](#1-project-summary)
- [2. Implementation approach](#2-implementation-approach)
- [3. Schedule baseline](#3-schedule-baseline)
- [4. Cost baseline](#4-cost-baseline)
- [5. Solution scope baseline](#5-solution-scope-baseline)
- [6. Project scope baseline](#6-project-scope-baseline)
- [7. Planning tools and workflow](#7-planning-tools-and-workflow)
- [8. Status reporting procedure](#8-status-reporting-procedure)
- [9. Environments](#9-environments)
- [10. Document list](#10-document-list)
- [11. Related documents](#11-related-documents)
- [Approval](#approval)

 ## Document control

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [name, role] | First draft |   |
| 1.0 | [YYYY-MM-DD] | [name, role] | Baseline for gate Project Initiated | [steering group chair] |

 ## 1. Project summary

 | Item | Value |
| --- | --- |
| Customer | [legal entity name] |
| Supplier | [implementation partner or consultant] |
| Project name and code | [name] / [code] |
| Contract or statement of work reference | [reference, date] |
| Executive sponsor (customer) | [name] |
| Sponsor (supplier) | [name] |
| Project managers | Customer: [name]. Supplier: [name] |
| Deployment option | [IFS Cloud hosted by IFS / remote deployment at customer] |
| Sites and companies in scope | [list] |
| Target go-live | [date or period, agreed in project] |
| Purpose in one sentence | [why the business is doing this project] |

 The detailed purpose, objectives and benefits are in the Project Scope Statement (template [IDK-02](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/02-project-scope-statement)). This plan describes how the work is controlled.

 ## 2. Implementation approach

 The project follows five phases. Each phase closes with a qualification gate at which the steering group confirms the agreed deliverables and releases the next phase.

 | Phase | What the phase achieves | Closing gate |
| --- | --- | --- |
| Initiate Project | Both teams mobilised, plan and scope finalised, controls in place | Project Initiated |
| Confirm Prototype | First prototype of selected end-to-end processes on customer sample data, solution scope confirmed | Solution Confirmed |
| Establish Solution | Design, build and test finished, closing with the Solution Acceptance Test | Solution Established |
| Implement Solution | Cutover prepared and rehearsed, users trained, Operational Readiness Test passed | Go Live Authorised |
| Go Live | Cutover executed, legacy retired, handover to support, project closed | Go Live Complete |

 Guiding principle for the solution: meet each process need with standard functionality first. Configurations, reports, integrations and modifications (CRIM) are kept to the smallest set the business can justify, because every tailored object has to survive each service update and release update.

 ## 3. Schedule baseline

 Baseline version: [n.n], dated [YYYY-MM-DD]. The live schedule is kept in [planning tool]. This table is the approved reference against which progress is reported.

 
### 3.1 Phases and gates

 | Phase | Planned start | Planned end | Gate | Planned gate date | Steering group meeting booked |
| --- | --- | --- | --- | --- | --- |
| Initiate Project | [YYYY-MM-DD] | [YYYY-MM-DD] | Project Initiated | [YYYY-MM-DD] | [yes/no] |
| Confirm Prototype | [YYYY-MM-DD] | [YYYY-MM-DD] | Solution Confirmed | [YYYY-MM-DD] | [yes/no] |
| Establish Solution | [YYYY-MM-DD] | [YYYY-MM-DD] | Solution Established | [YYYY-MM-DD] | [yes/no] |
| Implement Solution | [YYYY-MM-DD] | [YYYY-MM-DD] | Go Live Authorised | [YYYY-MM-DD] | [yes/no] |
| Go Live | [YYYY-MM-DD] | [YYYY-MM-DD] | Go Live Complete | [YYYY-MM-DD] | [yes/no] |

 Book all steering group dates now. Senior calendars are the first constraint a project meets.

 
### 3.2 Milestones

 | ID | Milestone | Phase | Owner | Baseline date | Evidence that it is reached |
| --- | --- | --- | --- | --- | --- |
| Example: M-03 | Build Place available to the project team, Use Place environments created for the agreed deployment option | Initiate Project | Supplier systems engineer | [YYYY-MM-DD] | Team members log in with named accounts; environment list in section 9 updated |
| Example: M-11 | Purchasing and inventory prototype demonstrated on customer sample data | Confirm Prototype | Customer functional lead, supply chain | [YYYY-MM-DD] | Demo held, attendee list and open points recorded, prototype approval signed |
| [ID] | [milestone] | [phase] | [role or name] | [YYYY-MM-DD] | [evidence] |

 
### 3.3 Calendar constraints

 | Constraint | Period | Effect on the plan |
| --- | --- | --- |
| Example: Financial year end and annual stock count | [period] | No cutover, no workshops needing finance or warehouse leads |
| [constraint] | [period] | [effect] |

 ## 4. Cost baseline

 Baseline version: [n.n], dated [YYYY-MM-DD]. Currency: [currency]. Commercial model: [fixed price / time and materials / mixed].

 | Cost element | Owner | Baseline | Basis of the figure | Reporting frequency |
| --- | --- | --- | --- | --- |
| Supplier services | Supplier PM | [amount] | [statement of work reference] | [agree in project] |
| Software subscription or licence | Customer PM | [amount] | [contract reference] | [agree in project] |
| Customer internal time and backfill | Customer PM | [amount] | [see [IDK-03](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/03-project-organisation-and-raci), time commitment] | [agree in project] |
| Infrastructure, devices, printers, scanners | Customer IT lead | [amount] | [quote reference] | [agree in project] |
| Travel and expenses | Supplier PM | [amount] | [policy reference] | [agree in project] |
| Contingency | Executive sponsor | [amount] | [agree in project] | At each steering group |
| CRIM allowance | Steering group | [amount] | [agree in project] | At each steering group |

 Rules:

 
1. Contingency is released only by [role].
2. Work outside the statement of work starts only after an approved change request (template [IDK-07](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure)).
3. Budget status is reported as: baseline, approved changes, actual to date, forecast to complete, variance.

 ## 5. Solution scope baseline

 Baseline version: [n.n], dated [YYYY-MM-DD]. The process model is maintained in [IFS Scope Tool or agreed repository]. The table below is a summary; the model is the detail.

 | Process area | End-to-end processes in scope | Sites and companies | Acceptance criterion | Accepting role |
| --- | --- | --- | --- | --- |
| Example: Procurement | Purchase requisition to supplier invoice match, including authorisation of requisitions | [sites] | Scenario scripts for the process pass in the Solution Acceptance Test, run with end-user permission sets and migrated supplier and part data, with no open operation-critical defects | Customer functional lead, procurement |
| Example: Inventory | Receipt, putaway, internal movement, counting and adjustment | [sites] | As above, including handheld scanning in the physical warehouse | Customer functional lead, warehouse |
| [area] | [processes] | [sites] | [criterion] | [role] |

 Known CRIM items at baseline:

 | ID | Type (C/R/I/M) | Description | Business reason | Status |
| --- | --- | --- | --- | --- |
| Example: CRIM-004 | I | Outbound purchase order data to the transport planning system, read through a standard projection over OData | Carrier booking depends on confirmed order lines | Logged, not yet specified |
| [ID] | [type] | [description] | [reason] | [status] |

 ## 6. Project scope baseline

 
### 6.1 Service assumptions and prerequisites

 | # | Assumption or prerequisite | Responsible | Needed by | Consequence if not met |
| --- | --- | --- | --- | --- |
| Example: A-02 | Core team members are released from daily duties for the agreed share of their time and their line managers have confirmed backfill | Executive sponsor | Start of Confirm Prototype | Workshops slip; schedule baseline is re-planned through change control |
| Example: A-07 | Customer extracts legacy data in the agreed format for each load cycle | Customer data lead | Each load cycle date in the migration plan | Load cycle is skipped, not shortened; validation time is protected |
| [ID] | [assumption] | [role] | [date or milestone] | [consequence] |

 
### 6.2 Roles and RACI reference

 Role descriptions, named people, time commitment and the RACI matrix by deliverable are kept in Project Organisation and RACI (template [IDK-03](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/03-project-organisation-and-raci)), version [n.n]. That document is part of this baseline.

 Default ownership of project documents:

 | Document group | Owner | Supported by |
| --- | --- | --- |
| Project management plan, scope statement, master implementation plan, workshop and activity plan | Supplier PM | Customer PM |
| Risk register, issue log, communication plan, strategies (testing, training, data, infrastructure, business change, legacy decommissioning) | Customer PM | Supplier PM |

 
### 6.3 Test and approval procedure

 | Item | Agreement |
| --- | --- |
| Who manages testing | Customer manages all testing except unit testing of developed objects. Supplier supports. |
| Test strategy document | Owner: [role]. Due: [YYYY-MM-DD]. Covers method, script template, test plan, script authors, metrics, testers, entry and exit criteria per cycle, environment per cycle, tools. |
| Test cycles | Verify application solution; verify with security and migrated data; Solution Acceptance Test; cutover rehearsal; Operational Readiness Test |
| Defect classification | Cause (data, user error, application error, wrong solution), blocks deployment (yes/no), contractual (yes/no), owner side, target closure date |
| Defect triage | [frequency, agree in project], chaired by [role] |
| Approval of a deliverable | Reviewer responds within [agree in project]. Silence is not approval. Approval is recorded in [tool or signed form]. |
| Approval of CRIM specifications | Integrations and modifications: functional specification approved by customer, plus commercial agreement, before development. Configurations and reports: specification approved by customer PM before build. |

 
### 6.4 Baseline change procedure

 
1. Any team member may raise a change. It is written down on the change request form ([IDK-07](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure)) before it is discussed in a meeting.
2. Both project managers assess impact on all four baselines.
3. Decision authority: [thresholds and roles, agree in project]. Anything touching scope, go-live date, budget or a modification goes to the steering group.
4. Approved changes produce a new baseline version. The change log lists what moved and why.
5. Work on a change does not start before approval.

 ## 7. Planning tools and workflow

 | Purpose | Tool | Maintained by | Update rhythm |
| --- | --- | --- | --- |
| Master implementation plan | [tool] | Supplier PM | [agree in project] |
| Workshop and activity plan | [tool] | Supplier PM with functional leads | [agree in project] |
| Project tracker (progress and indicators per workstream) | [tool] | Both PMs | [agree in project] |
| Risk register and issue log | [tool] | Customer PM | Reviewed at each project team meeting |
| Process model and scope | [IFS Scope Tool or agreed repository] | Solution architect | After each workshop |
| Test scripts and defects | [tool] | Customer test lead | Daily during test cycles |
| Document repository | [location] | [role] | Continuous |

 Planning workflow: each workstream lead plans the coming period, reports what was completed, and reviews the gap with the project managers. The cycle is plan, do, review. Tasks have one named owner and a date. Customer tasks (testing, data cleansing, decisions) sit in the same plan as supplier tasks.

 ## 8. Status reporting procedure

 | Report | Author | Audience | Frequency | Content | Channel |
| --- | --- | --- | --- | --- | --- |
| Workstream status | Workstream lead | Both PMs | [agree in project] | Done, next, blocked, decisions needed | [channel] |
| Project status report | Both PMs | Sponsors, steering group | [agree in project] | Progress vs plan, milestones, budget, top risks and issues, decisions needed, gate readiness ([IDK-06](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/06-steering-group-pack) format) | [channel] |
| PM-to-PM review | Both PMs | Internal | Weekly | Plan, resources, risks, upcoming customer tasks | Meeting |

 Status colours are defined once: green means on baseline, amber means off baseline with a recovery plan the PMs own, red means off baseline and needing a steering group decision.

 ## 9. Environments

 | Environment | Place | Purpose | Data | Refresh rule | Access managed by |
| --- | --- | --- | --- | --- | --- |
| Example: Development and configuration | Build Place | Build and unit test configurations and developed objects before delivery | Supplier test data | [agree in project] | Supplier technical solution manager |
| Example: Configuration and test | Use Place | Workshops, prototype, test cycles | Customer sample data, then migrated data | Refreshed from [source] before each test cycle | Customer IT lead |
| Example: Production | Use Place | Receives verified configuration as it is approved; becomes the baseline after static data load and security definition | Production data | Not refreshed | Customer IT lead |
| [environment] | [place] | [purpose] | [data] | [rule] | [role] |

 Update cadence: the approach to service updates and release updates during the project is [agree in project]. Freeze window before go-live: [agree in project]. The tailoring strategy and the update cadence are reviewed together, because the amount of tailoring limits how often the customer can update.

 ## 10. Document list

 Agree this list now and show an example of each document type. Documents requested later are a change request.

 
### 10.1 Documents the supplier will write

 | Document | Level of detail agreed | Example shown to customer | Due |
| --- | --- | --- | --- |
| Example: Functional specification per integration and modification | Purpose, trigger, data mapping by field, error handling, test cases | [yes/no, date] | Before development of each object |
| [document] | [detail] | [yes/no] | [date or milestone] |

 
### 10.2 Documents the supplier will not write

 | Document | Written by | Supplier contribution |
| --- | --- | --- |
| Example: Step-by-step guides in end-user language | Customer functional teams | Review for accuracy during solution workshops |
| Example: Test scripts for acceptance and readiness tests | Customer functional teams | Script template and review of coverage |
| [document] | [role] | [contribution] |

 ## 11. Related documents

 | Document | Template | Owner | Status |
| --- | --- | --- | --- |
| Project Scope Statement | [IDK-02](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/02-project-scope-statement) | Supplier PM | [status] |
| Project Organisation and RACI | [IDK-03](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/03-project-organisation-and-raci) | Both PMs | [status] |
| Risk Register and Issue Log | [IDK-04](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/04-risk-register-and-issue-log) | Customer PM | [status] |
| Communication Plan and Stakeholder Analysis | [IDK-05](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/05-communication-plan-and-stakeholder-analysis) | Customer PM | [status] |
| Steering Group Pack | [IDK-06](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/06-steering-group-pack) | Both PMs | [status] |
| Change Request and Change Control Procedure | [IDK-07](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure) | Both PMs | [status] |
| Qualification Gate Checklists | [IDK-08](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/08-qualification-gate-checklists) | Both PMs | [status] |

 ## Approval

 | Name | Role | Date | Signature |
| --- | --- | --- | --- |
| [name] | Executive sponsor (customer) | [YYYY-MM-DD] | ______________________ |
| [name] | Sponsor (supplier) | [YYYY-MM-DD] | ______________________ |
| [name] | Customer project manager | [YYYY-MM-DD] | ______________________ |
| [name] | Supplier project manager | [YYYY-MM-DD] | ______________________ |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/01-project-management-plan.md)

## Project Closure and Lessons Learned Template (IDK-24)

Template IDK-24, version 1.0. Phase: Go Live.

 ## How to use this template

 
- Write this after the go-live support period, once the solution is running as agreed and the handover to support is complete.
- The two project managers write it together. The steering group agrees it. After that the project no longer exists, so everything still open needs a named owner in the line organisation.
- Collect lessons from the whole team, not only from the project managers. Run the session in section 7 before people are released.
- Rows marked `Example:` show the expected level of detail. Delete them from your working copy.
- Be factual. A closure report that hides what went wrong has no value for the next project.

 | Field | Value |
| --- | --- |
| Template ID | IDK-24 |
| Phase | Go Live |
| Owner | Customer project manager |
| Approver | Steering group |
| Qualification gate | Go Live Complete |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Gate evidence: Go Live Complete](#1-gate-evidence-go-live-complete)
- [2. Objectives versus outcome](#2-objectives-versus-outcome)
- [3. Benefits tracking handover to sponsor](#3-benefits-tracking-handover-to-sponsor)
- [4. Residual issues with owners](#4-residual-issues-with-owners)
- [5. Closure of risk register and issue log](#5-closure-of-risk-register-and-issue-log)
- [6. Documentation inventory](#6-documentation-inventory)
- [7. Lessons learned](#7-lessons-learned)
- [8. Team release](#8-team-release)
- [9. Steering group closure approval](#9-steering-group-closure-approval)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Customer | [Legal entity] |
| Go-live date(s) | [date per site or module] |
| Proposed closure date | [YYYY-MM-DD] |
| Document owner | [Name, customer project manager] |
| Co-author | [Name, supplier project manager] |
| Status | [Draft / Submitted / Agreed] |
| Version | [x.y] |
| Storage location | [Link] |
| Related documents | [Project scope statement, project management plan, business case, handover to support (template [IDK-22](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/22-handover-to-support)), update strategy (template [IDK-23](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/23-update-strategy-evergreen))] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| [0.1] | [YYYY-MM-DD] | [name] | [First draft] |

 ## 1. Gate evidence: Go Live Complete

 | # | Criterion | Evidence | Status |
| --- | --- | --- | --- |
| 1 | Cutover completed | [Closed cutover checklist] | [Met / Not met] |
| 2 | Solution operates as agreed | [Go-live period issue log; process owner confirmations] |   |
| 3 | Users can operate the solution | [Expert user feedback; support case trend] |   |
| 4 | Support plan in place | [Support agreement; internal support model] |   |
| 5 | Handover to support complete | [Signed template [IDK-22](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/22-handover-to-support)] |   |
| 6 | Project evaluation done | [This document, sections 2 and 7] |   |

 ## 2. Objectives versus outcome

 
### 2.1 Project objectives

 | # | Objective from the scope statement | Acceptance criterion | Outcome | Assessment | Comment |
| --- | --- | --- | --- | --- | --- |
| [n] | [text] | [text] | [text] | [Met / Partly met / Not met / Too early to say] | [text] |
| Example: 2 | Example: Replace the legacy purchasing system with standard IFS Cloud procurement at all sites in scope | Example: All purchase orders created in IFS Cloud; legacy read-only | Example: Live at all sites in scope; legacy read-only since cutover | Example: Met | Example: Supplier order confirmation still handled by email, as designed |

 
### 2.2 Baselines

 | Baseline | Approved baseline | Approved changes | Final | Variance explained |
| --- | --- | --- | --- | --- |
| Solution scope | [ref] | [Change request IDs] | [ref] | [text] |
| Project scope | [ref] | [Change request IDs] | [ref] | [text] |
| Schedule | [Go-live date in baseline] | [Change request IDs] | [Actual date] | [text] |
| Cost | [ref to budget] | [Change request IDs] | [ref to final figures] | [text] |

 
### 2.3 Tailoring outcome

 | CRIM type | Identified in Confirm Prototype | Delivered | Avoided by using standard | Comment |
| --- | --- | --- | --- | --- |
| Configurations | [n] | [n] | [n] |   |
| Reports | [n] | [n] | [n] |   |
| Integrations | [n] | [n] | [n] |   |
| Modifications | [n] | [n] | [n] |   |

 The aim was to meet process needs with standard functionality first. State plainly whether it held: [text].

 ## 3. Benefits tracking handover to sponsor

 The project delivers the capability. The business delivers the benefits. The sponsor owns the business case and stays accountable for benefit realisation after the project closes.

 | # | Benefit from the business case | Measure | Baseline value | Target and date | Status at closure | Benefit owner | Next review |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [n] | [text] | [how measured, data source] | [value, date] | [value, date] | [text] | [name, line role] | [date, forum] |
| Example: 1 | Example: Fewer late supplier deliveries discovered only at the dock | Example: Share of purchase order lines received after the confirmed date, from a lobby on purchase order receipts | [value, date] | [value, date] | Example: Measurement running since go-live; too early to compare | Example: Procurement manager | [date, management meeting] |

 | Handover item | Value |
| --- | --- |
| Benefits review forum after closure | [Which standing meeting takes over from the steering group] |
| Frequency | [agree in project] |
| Sponsor acceptance of benefit tracking | [name, date] |

 ## 4. Residual issues with owners

 Everything still open on the closure date. Each line needs an owner outside the project.

 | ID | Description | Type | Impact | Workaround | Owner after closure | Target date | Tracked where |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [ID] | [text] | [Defect / Data / Training / Process / Deferred scope / Basic data to adjust] | [text] | [text] | [name, line role] | [YYYY-MM-DD] | [Support case / IT backlog / Rollout project] |
| Example: R-006 | Example: Supplier order report shows the custom project code only on the first page | Example: Defect | Example: Low; affects multi-page orders | Example: Code added to the order note | Example: Customer system owner, fix by supplier support | [YYYY-MM-DD] | Example: Support case `[ref]` |

 Deferred scope, agreed not to be delivered by this project:

 | Item | Reason for deferral | Decision reference | Proposed home |
| --- | --- | --- | --- |
| [text] | [text] | [Change request or steering group minute] | [Next phase / Rollout / Dropped] |

 ## 5. Closure of risk register and issue log

 | Register | Open at closure | Action | New owner | Confirmed |
| --- | --- | --- | --- | --- |
| Risk register | [n] | [Each open risk: closed as no longer relevant, or transferred] | [Customer system owner / IT risk register] | [ ] |
| Issue log | [n] | [Each open issue: closed, or moved to section 4] | [See section 4] | [ ] |
| Change request log | [n] | [Each open request: approved and delivered, rejected, or moved to deferred scope] | [Customer system owner] | [ ] |
| Defect log | [n] | [Open items moved to support cases] | [Support] | [ ] |
| Action lists from steering group minutes | [n] | [Closed or transferred] | [names] | [ ] |

 Risks transferred to operations:

 | Risk | Why it remains | Owner | Mitigation in place |
| --- | --- | --- | --- |
| [text] | [text] | [name] | [text] |
| Example: Knowledge of the solution concentrated in a few core team members | Example: Core team returns to line roles | Example: Customer system owner | Example: Core team forms the permanent business systems team; guides and process model kept current |

 Registers archived read-only on [YYYY-MM-DD] at [location].

 ## 6. Documentation inventory

 | Document | Final version | Owner after closure | Location | Kept current after closure |
| --- | --- | --- | --- | --- |
| Project scope statement and change requests | [x.y] | [name] | [link] | No, archive |
| Project management plan | [x.y] | [name] | [link] | No, archive |
| Book of Rules documents | [x.y] | [Process owners] | [link] | Yes |
| Process model | [ref] | [Customer system owner] | [IFS Scope Tool project or export: link] | Yes |
| Decision log with reasoning | [x.y] | [Customer system owner] | [link] | Yes |
| CRIM log with functional and test specifications | [x.y] | [Customer system owner, support] | [link] | Yes |
| Interface register | [x.y] | [Integration lead] | [link] | Yes |
| Role matrix and permission set documentation | [x.y] | [Security lead] | [link] | Yes |
| Data migration plan, mappings, validation sign-offs | [x.y] | [name] | [link] | No, archive. Keep for audit: [retention period per company policy] |
| Test strategy, SAT and ORT scripts and sign-offs | [x.y] | [Customer system owner] | [link] | Yes, scripts become the regression pack |
| Training plan, course material, step-by-step guides | [x.y] | [Training lead] | [link] | Yes |
| Cutover plan, checklist, rehearsal logs | [x.y] | [name] | [link] | No, archive. Reuse for rollouts |
| Go-live readiness decision | [x.y] | [name] | [link] | No, archive |
| Handover to support | [x.y] | [Support manager] | [link] | Yes |
| Update strategy | [x.y] | [Customer system owner] | [link] | Yes |
| Steering group papers and minutes |   | [name] | [link] | No, archive |

 Access to the archive after closure: [who, how]. Supplier copies of customer documents: [retained / returned / deleted, per contract].

 ## 7. Lessons learned

 
### 7.1 How the lessons were collected

 | Item | Value |
| --- | --- |
| Session date(s) | [YYYY-MM-DD] |
| Participants | [Core team, expert users, technical team, both PMs, sponsor, supplier consultants] |
| Facilitator | [Someone outside the project management, if possible] |
| Other input | [Survey, steering group feedback, support feedback after handover] |

 
### 7.2 What to repeat

 | # | Area | What worked | Why it worked | Recommendation for the next project |
| --- | --- | --- | --- | --- |
| [n] | [Governance / Team / Scope / Solution / Data / Testing / Training / Cutover / Change management / Supplier cooperation] | [text] | [text] | [text] |
| Example: 1 | Example: Data | Example: Supplier and part cleansing started before the prototype was built | Example: Data owners were named early and had released time | Example: Name data owners and start the data inventory at project start |

 
### 7.3 What to change

 | # | Area | What happened | Effect | Root cause | Recommendation for the next project |
| --- | --- | --- | --- | --- | --- |
| [n] | [area] | [text] | [text] | [text] | [text] |
| Example: 1 | Example: Testing | Example: Exception scenarios were scripted late | Example: Several wrong-solution findings surfaced only in SAT and went through change control under time pressure | Example: Scripting was planned around regular cases; process owners joined the review late | Example: Agree the exception list per process with process owners before scripting starts |

 
### 7.4 Where the lessons go

 | Recipient | What they receive | Sent by | Date |
| --- | --- | --- | --- |
| [Customer project office / IT governance] | [Sections 7.2 and 7.3] | [Customer PM] | [YYYY-MM-DD] |
| [Supplier delivery organisation] | [Sections 7.2 and 7.3, as agreed with the customer] | [Supplier PM] | [YYYY-MM-DD] |
| [Next rollout or phase project manager] | [Full document] | [Customer PM] | [YYYY-MM-DD] |

 ## 8. Team release

 | Name | Project role | Released to | Release date | Continuing role for the solution | Line manager informed |
| --- | --- | --- | --- | --- | --- |
| [name] | [role] | [Line role / Business systems team / Next rollout] | [YYYY-MM-DD] | [Process owner / Expert user / None] | [ ] |
| Example: [name] | Example: Functional lead, procurement | Example: Procurement department, with agreed time in the business systems team | [YYYY-MM-DD] | Example: Process owner procurement; approves update regression results | [ ] |

 | Closing item | Done |
| --- | --- |
| Backfill arrangements ended or made permanent | [ ] |
| Supplier consultants released; project accounts and elevated access removed | [ ] |
| Permanent business systems team named, with system owner | [ ] |
| Expert user network confirmed, with a way to replace leavers | [ ] |
| Project workspace, mailboxes and meeting series closed | [ ] |
| Team and business thanked; results communicated | [ ] |
| Final invoices and contract closure items settled | [ ] |

 ## 9. Steering group closure approval

 | Field | Value |
| --- | --- |
| Meeting date | [YYYY-MM-DD] |
| Present | [names, roles] |
| Papers sent in advance on | [YYYY-MM-DD] |
| Gate "Go Live Complete" | [Confirmed / Not confirmed: reason] |
| Residual issues and owners (section 4) | [Accepted / Changes required] |
| Benefits tracking handover (section 3) | [Accepted by sponsor: Yes / No] |
| Decision | [Project closed on: date / Closure postponed until: condition] |
| Steering group dissolved on | [YYYY-MM-DD] |
| Post-closure review planned | [date, owner, scope] |

 ## Approval

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer project manager (owner) | [name] | [Submitted] | [YYYY-MM-DD] |   |
| Supplier project manager | [name] | [Agreed] | [YYYY-MM-DD] |   |
| Customer system owner | [name] | [Accepts residual issues and documentation] | [YYYY-MM-DD] |   |
| Project sponsor | [name] | [Accepts benefits tracking; approves closure] | [YYYY-MM-DD] |   |
| Steering group chair | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/24-project-closure-and-lessons-learned.md)

## Update Strategy (Evergreen) Template (IDK-23)

Template IDK-23, version 1.0. Phase: Initiate Project (first decision), maintained after Go Live.

 ## How to use this template

 
- Start this document at the beginning of the project, not after go-live. The cadence you choose here shapes design decisions from the first workshop.
- Service updates and release updates are the only route by which core fixes and new features reach your system. Plan them as a recurring routine with a calendar, not as separate projects.
- Sections 1 to 3 and 7 are decisions. Sections 4 to 6 are the working method. Section 5 is copied once per update.
- Rows marked `Example:` show the expected level of detail. Delete them from your working copy.
- All cadence values are yours to decide within what your deployment option and contract allow. Check those terms before filling in section 1.

 | Field | Value |
| --- | --- |
| Template ID | IDK-23 |
| Phase | Initiate Project (first decision), maintained after Go Live |
| Owner | Customer system owner |
| Approver | Steering group during the project, customer IT governance after closure |
| Qualification gate | Project Initiated (cadence decided), Go Live Complete (operating model confirmed) |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Update cadence decision](#1-update-cadence-decision)
- [2. Roles](#2-roles)
- [3. Calendar](#3-calendar)
- [4. Environments used](#4-environments-used)
- [5. Impact assessment per update](#5-impact-assessment-per-update)
- [6. Tailoring policy and how it limits cadence](#6-tailoring-policy-and-how-it-limits-cadence)
- [7. Communication and training for changes](#7-communication-and-training-for-changes)
- [8. Decision log](#8-decision-log)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Customer | [Legal entity] |
| Solution | [IFS Cloud, companies and sites in scope] |
| Document owner | [Name, customer system owner] |
| Status | [Draft / Approved / In operation] |
| Version | [x.y] |
| Storage location | [Link] |
| Related documents | [CRIM log, interface register, handover to support (template [IDK-22](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/22-handover-to-support)), SAT scripts (template [IDK-18](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/18-sat-ort-test-script-and-signoff)), support agreement] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| [0.1] | [YYYY-MM-DD] | [name] | [First draft] |

 ## 1. Update cadence decision

 | Question | Decision | Reason | Decided by, date |
| --- | --- | --- | --- |
| Deployment option and what it requires for updates | [Cloud service / Remote deployment; contractual terms: link] |   |   |
| How often do we take service updates? | [agree in project] | [text] | [name, date] |
| How soon after release do we take a service update? | [agree in project] | [text] | [name, date] |
| Which release updates do we take? | [agree in project] | [text] | [name, date] |
| How far behind the current release may we be at most? | [agree in project, within vendor support policy] | [text] | [name, date] |
| Freeze periods with no updates | [Go-live, period and year end, business peaks: dates] | [text] | [name, date] |
| Who may approve an exception to this cadence? | [role] |   |   |

 Why staying current matters for [Customer], in our own words: [Falling behind raises security exposure, raises operating cost because each later jump is larger, and narrows the support available. State what this means for this business.]

 Review of this decision: [when and by whom; at least after the first release update taken in operation].

 ## 2. Roles

 | Role | Name | Responsibility in an update |
| --- | --- | --- |
| System owner | [name] | Owns this strategy and the calendar. Approves each update for production. |
| Update coordinator | [name] | Runs the impact assessment, books environments and testers, tracks the checklist. |
| Process owners | [names per area] | Review release notes for their area. Decide which new features to adopt. Sign regression results. |
| Expert users | [names] | Run regression scripts. Tell colleagues what changes. |
| Technical lead | [name] | Environments, delivery route, Build Place work, projections and integration checks. |
| Integration owners | [names per interface] | Confirm each interface after the update, with the external party where needed. |
| Security lead | [name] | Reviews new and changed projections and permission set impact. |
| Implementation partner / support | [name, contract] | [Uplift of modifications, advice, agreed share of testing] |
| Third-party vendors | [list] | Confirm compatibility of their extension or service with the target level. |

 ## 3. Calendar

 | Update | Type | Available from | Impact assessment | In test environment | Regression test window | Production | Freeze conflicts checked |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [identifier] | [Service update / Release update] | [YYYY-MM-DD] | [YYYY-MM-DD] | [YYYY-MM-DD] | [from, to] | [YYYY-MM-DD] | [Yes / No] |
| Example: `[release identifier]` | Example: Release update | [YYYY-MM-DD] | [YYYY-MM-DD] | [YYYY-MM-DD] | [from, to] | [YYYY-MM-DD] | Example: Yes, avoids year-end close and the autumn peak |

 Publish the calendar to: [process owners, expert users, integration owners, partner, third-party vendors]. Rolling horizon: [agree in project].

 ## 4. Environments used

 | Step | Environment | Place | Rule |
| --- | --- | --- | --- |
| Uplift and rebuild of modifications | [name] | Build Place | [Who does it, how deliveries are produced] |
| First technical check | [name] | Use Place | [Refreshed from production before the update is applied: Yes / No] |
| Regression and integration test | [name] | Use Place | [Production-like data; integrations pointed at test endpoints] |
| Training on changes, if needed | [name] | Use Place | [text] |
| Production | [name] | Use Place | [Applied in the agreed window; backup confirmed first] |

 Delivery route and approvals between environments: [text or link to template [IDK-22](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/22-handover-to-support), section 5].

 ## 5. Impact assessment per update

 Copy this section for each update. Store the completed copy with the decision log.

 
### 5.1 Update header

 | Field | Value |
| --- | --- |
| Update | [identifier, type] |
| Current level in production | [level] |
| Target level | [level] |
| Coordinator | [name] |
| Assessment date | [YYYY-MM-DD] |

 
### 5.2 Release notes review

 | Area | Reviewer | Change relevant to us | Effect | Action | Adopt new feature |
| --- | --- | --- | --- | --- | --- |
| [area] | [process owner] | [text] | [None / Procedure change / Guide change / Configuration needed / Training needed] | [text, owner] | [Yes / No / Later] |
| Example: Procurement | [name] | Example: Changed layout of a page used daily by purchasers | Example: Guide change | Example: Update the guide "Convert to order"; brief purchasers through expert users | Example: Not applicable |

 Also review: deprecation and obsolescence notices, security notes, changes to technical prerequisites. Reviewer: [technical lead].

 
### 5.3 CRIM re-verification list

 Source: CRIM log (template [IDK-10](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/10-crim-log)), update-impact note per row, and the CRIM list in Handover to Support (template [IDK-22](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/22-handover-to-support), section 6).

 | CRIM ID | Type | Touches changed area | Action | Test specification to run | Owner | Result |
| --- | --- | --- | --- | --- | --- | --- |
| [ID] | [C / R / I / M] | [Yes / No / Unknown] | [None / Retest / Adjust / Uplift in Build Place / Retire, standard now covers it] | [link, version] | [name] | [Pass / Fail / Open] |
| Example: CRIM-017 | Example: Configuration | Example: Yes, purchase order line | Example: Retest: custom field visible on the page and on the supplier order report | [link, x.y] | [name] |   |

 At every release update ask of each object: can standard functionality replace it now? Each object retired makes the next update lighter.

 
### 5.4 Projections and integrations check

 | Interface / consumer | Projections or API used | Changed or deprecated in this update | Test performed | External party confirmation needed | Owner | Result |
| --- | --- | --- | --- | --- | --- | --- |
| [name] | [list] | [Yes / No: detail] | [text] | [Yes / No] | [name] |   |
| Example: External read-only monitoring service | Example: Purchase order and supplier projections read through OData | [Yes / No] | Example: Service account can still read the projections; fields in use still returned; a test run produces the expected result | Example: Vendor confirms compatibility with the target level | [name] |   |

 Also check: service accounts and permission sets still valid; certificates and credentials not expiring in the window; routing, scheduled jobs and workflows running after the update.

 
### 5.5 Regression scripts to run

 Reuse the SAT scripts (template [IDK-18](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/18-sat-ort-test-script-and-signoff)). Keep them current; they are the customer's regression pack.

 | Scenario ID | Process | Why selected | Tester | Environment | Result | Defect ID |
| --- | --- | --- | --- | --- | --- | --- |
| [ID] | [process] | [Core flow / Touched by release notes / Touches CRIM object / Integration] | [name] | [name] | [Pass / Fail] |   |
| Example: P2P-01 | Example: Procure to pay, regular case | Example: Core flow, always run | [expert user] | [name] |   |   |

 Minimum regression scope for a service update: [agree in project]. For a release update: [agree in project].

 
### 5.6 Go decision for production

 | Field | Value |
| --- | --- |
| Open defects | [list with classification as in template [IDK-17](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/17-test-strategy), section 9] |
| Decision | [Apply on planned date / Apply with conditions / Postpone to: date] |
| Backup confirmed before update | [Yes / No] |
| Way back if the update fails | [text] |
| Decided by | [system owner, date] |

 ## 6. Tailoring policy and how it limits cadence

 Principle: meet the process need with standard functionality first. Keep configurations, reports, integrations and modifications as few as possible. The amount of tailoring, and how deeply it reaches into the core, sets the ceiling on how often [Customer] can update.

 | Tailoring type | Policy | Approval needed | Cost carried at every update |
| --- | --- | --- | --- |
| Standard functionality with changed business procedure | Preferred | Process owner | None |
| Configuration in the web client (custom fields, pages, lobbies, events, workflows) | Allowed with a specification | [Customer PM / system owner] | Retest |
| Reports | Allowed with a specification; prefer standard reports and lobbies | [Customer PM / system owner] | Retest, layout check |
| Integrations | Allowed with an approved functional specification; use projections and standard APIs | [Steering group / IT governance] | Interface test, often with the external party |
| Modifications | Exception only, with a written business case | [Steering group / IT governance] | Uplift in Build Place, rebuild, delivery, full retest |

 Rules:

 
1. Every new CRIM request states its recurring update cost before approval: [who estimates].
2. No tailoring without a functional specification and a test specification. Without both, the object cannot be re-verified.
3. The CRIM log is the single list. An object that is not in the log is not supported.
4. Requests to modify the system to avoid a change in working practice go to [approver] and are expected to be refused.
5. [Project-specific rule]

 Current tailoring footprint: [counts per CRIM type from the log, YYYY-MM-DD]. Trend target: [agree in project].

 ## 7. Communication and training for changes

 | Audience | What they receive | From whom | When | Channel |
| --- | --- | --- | --- | --- |
| All users | [Update date, downtime, visible changes in plain language] | [System owner] | [agree in project] | [channel] |
| Users of changed processes | [Updated step-by-step guide, short briefing or recording] | [Expert users] | [Before production date] | [channel] |
| Expert users | [Walkthrough of relevant changes in the test environment] | [Process owners] | [During regression window] | [session] |
| Service desk | [Known changes, known issues, who to escalate to] | [Update coordinator] | [Before production date] | [channel] |
| External parties | [Interface test dates, expected changes] | [Integration owners] | [agree in project] | [channel] |
| Management | [Calendar, outcome, exceptions to cadence] | [System owner] | [agree in project] | [report] |

 Guides and training material are updated in the same cycle as the system. Owner of the guide library: [name].

 ## 8. Decision log

 | # | Date | Decision | Reason | Decided by | Review date |
| --- | --- | --- | --- | --- | --- |
| [n] | [YYYY-MM-DD] | [text] | [text] | [name, role] | [YYYY-MM-DD] |
| Example: 1 | [YYYY-MM-DD] | Example: Postpone service update `[identifier]` until after period close | Example: Regression window collides with closing activities in finance | Example: System owner | [YYYY-MM-DD] |

 ## Approval

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer system owner (owner) | [name] | [Submitted] | [YYYY-MM-DD] |   |
| Customer IT lead | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |
| Customer project manager | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |
| Supplier project manager or solution architect | [name] | [Reviewed] | [YYYY-MM-DD] |   |
| Steering group chair / IT governance chair | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/23-update-strategy-evergreen.md)

## Handover to Support Template (IDK-22)

Template IDK-22, version 1.0. Phase: Go Live.

 ## How to use this template

 
- The project manager starts the handover and the project budget pays for it. Plan it as a project task with a date, not as something that happens when people have time.
- Prerequisites: the customer is live (a partial handover per site or module is possible), the solution is accepted, and the documentation is in English.
- Write for a support consultant who has never met this customer. If that person cannot find a specification or reproduce a test from this document, the handover is not finished.
- Rows marked `Example:` show the expected level of detail. Delete them from your working copy.
- Close with a recorded handover meeting between the project team and support (section 12). Without the meeting the handover has not happened.

 | Field | Value |
| --- | --- |
| Template ID | IDK-22 |
| Phase | Go Live |
| Owner | Supplier project manager |
| Approver | Support manager and customer project manager |
| Qualification gate | Go Live Complete |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Customer information](#1-customer-information)
- [2. Project contacts](#2-project-contacts)
- [3. Handover checklist](#3-handover-checklist)
- [4. Solution overview](#4-solution-overview)
- [5. Environments](#5-environments)
- [6. CRIM objects handed over](#6-crim-objects-handed-over)
- [7. Third-party integrations](#7-third-party-integrations)
- [8. Extensions and localisations](#8-extensions-and-localisations)
- [9. Delivery schedule and readiness](#9-delivery-schedule-and-readiness)
- [10. Basic data to adjust after go-live](#10-basic-data-to-adjust-after-go-live)
- [11. Known issues and workarounds](#11-known-issues-and-workarounds)
- [12. Handover meeting record](#12-handover-meeting-record)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Customer | [Legal entity] |
| Handover scope | [Full / Partial: sites, modules] |
| Document owner | [Name, supplier project manager] |
| Receiving support organisation | [Name, team] |
| Status | [Draft / Reviewed by support / Accepted] |
| Version | [x.y] |
| Storage location | [Link, accessible to support] |
| Related documents | [Project closure (template [IDK-24](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/24-project-closure-and-lessons-learned)), update strategy (template [IDK-23](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/23-update-strategy-evergreen)), CRIM log, interface register] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| [0.1] | [YYYY-MM-DD] | [name] | [First draft] |

 ## 1. Customer information

 | Field | Value |
| --- | --- |
| Legal entity and group structure | [text] |
| Industry and main business | [text] |
| Companies and sites live in IFS Cloud | [list] |
| Countries and languages in use | [list] |
| Deployment option | [Cloud service / Remote deployment] |
| IFS Cloud release and service update level at handover | [release, update] |
| Go-live date(s) | [date per site or module] |
| User base | [Named users by type: link to licence record] |
| Business-critical periods | [Period end, seasonal peaks, shift patterns] |
| Support agreement reference | [Contract, service hours, response commitments: link] |
| Further rollouts planned | [Sites, modules, dates] |

 ## 2. Project contacts

 | Role | Name | Organisation | Contact | Available after handover until |
| --- | --- | --- | --- | --- |
| Customer sponsor | [name] | [Customer] | [email, phone] | [YYYY-MM-DD] |
| Customer project manager | [name] | [Customer] | [email, phone] | [YYYY-MM-DD] |
| Customer system owner after go-live | [name] | [Customer] | [email, phone] | Permanent |
| Customer IT lead | [name] | [Customer] | [email, phone] | Permanent |
| Expert users per area | [link to list] | [Customer] |   | Permanent |
| Supplier project manager | [name] | [Supplier] | [email, phone] | [YYYY-MM-DD] |
| Solution architect | [name] | [Supplier] | [email, phone] | [YYYY-MM-DD] |
| Technical solution manager | [name] | [Supplier] | [email, phone] | [YYYY-MM-DD] |
| Application consultants per area | [names] | [Supplier] | [email] | [YYYY-MM-DD] |
| Account manager | [name] | [Supplier] | [email, phone] | Permanent |

 Who at the customer may log support cases: [names or rule]. Who may approve chargeable work: [names].

 ## 3. Handover checklist

 | # | Item | Done | Evidence / link | Comment |
| --- | --- | --- | --- | --- |
| 1 | Customer is live in the handover scope | [ ] | [Go-live confirmation] |   |
| 2 | Solution accepted by the customer | [ ] | [SAT and ORT sign-off] |   |
| 3 | Documentation is in English | [ ] |   |   |
| 4 | Process model is current and accessible to support | [ ] | [link] |   |
| 5 | CRIM log complete, with latest functional and test specifications | [ ] | [Section 6] |   |
| 6 | Third-party integrations listed with owners and accounts | [ ] | [Section 7] |   |
| 7 | Extensions and localisations listed | [ ] | [Section 8] |   |
| 8 | Environments documented; support has the access it needs | [ ] | [Section 5] |   |
| 9 | Delivery schedule and readiness reviewed | [ ] | [Section 9] |   |
| 10 | Basic data to adjust after go-live listed with owners | [ ] | [Section 10] |   |
| 11 | Known issues and workarounds listed; open cases transferred | [ ] | [Section 11] |   |
| 12 | Project accounts and elevated access removed or given an end date | [ ] | [Account list] |   |
| 13 | Handover meeting held and recorded | [ ] | [Section 12] |   |

 ## 4. Solution overview

 | Item | Value |
| --- | --- |
| Process model | [Link to the project in the IFS Scope Tool or exported model] |
| End-to-end processes in use | [list] |
| Operating model summary | [Link to the approved Book of Rules documents] |
| Key design decisions | [Link to decision log. Include the reasoning, not only the outcome.] |
| Step-by-step guides | [Library link] |
| Roles and permission sets | [Link to role matrix] |
| Lobbies in daily use | [list with owner] |
| Workflows and event actions in use | [list with purpose and owner] |

 Plain-language summary of how this customer uses IFS Cloud and what is unusual about it: [short text. This is the paragraph a new support consultant reads first.]

 ## 5. Environments

 | Environment | Place | Purpose | Release and update level | Refreshed from / when | Access for support | Owner |
| --- | --- | --- | --- | --- | --- | --- |
| [name] | [Build Place / Use Place] | [purpose] | [level] | [source, date] | [Yes / No, how] | [name] |
| Example: PROD | Example: Use Place | Example: Production | [level] | Not applicable | Example: On request through the customer IT lead, time-limited | Example: Customer IT lead |
| Example: [name] | Example: Build Place | Example: Development and delivery of modifications | [level] | [YYYY-MM-DD] | Example: Supplier technical team | Example: Technical solution manager |

 Delivery route from Build Place to Use Place production: [steps, approver, who applies deliveries]. Code repository and branch rules: [link, text]. Identity provider and single sign-on setup: [summary, owner].

 ## 6. CRIM objects handed over

 Every configuration, report, integration and modification delivered by the project. A fix cannot be verified without a test specification, so a missing link in this table is an open handover item.

 | CRIM ID | Type | Name and purpose | Process | Functional specification (link, version) | Test specification (link, version) | Version in production | Built by | Re-verify at each update |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [ID] | [C / R / I / M] | [text] | [process] | [link, x.y] | [link, x.y] | [x.y] | [name] | [Yes / No] |
| Example: CRIM-017 | Example: Configuration | Example: Custom field "Internal project code" on purchase order line, shown on the supplier order report | Example: Procure to pay | [link, x.y] | [link, x.y] | [x.y] | [name] | Yes |
| Example: CRIM-003 | Example: Integration | Example: Outbound payment file to the bank in the agreed format | Example: Procure to pay, supplier payment | [link, x.y] | [link, x.y] | [x.y] | [name] | Yes |

 Confirmation: specifications above are the latest versions and match what runs in production. Confirmed by [technical solution manager] on [YYYY-MM-DD].

 ## 7. Third-party integrations

 Include everything that reads from or writes to IFS Cloud, also services the project did not build.

 | # | System / service | Purpose | Direction | Projections / interface used | Account and permission set | Authentication | Customer owner | Vendor contact | Check after each update | How to remove |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [n] | [name] | [purpose] | [Inbound / Outbound / Read-only] | [list] | [account, permission set] | [method] | [name] | [contact] | [what to verify] | [steps] |
| Example: 1 | Example: External monitoring service for purchasing exceptions, supplied by a third party, running inside the customer network | Example: Alerts purchasers to orders the supplier has not confirmed and to late deliveries | Example: Read-only. Reads through OData. Writes nothing to IFS Cloud and installs nothing in it. | Example: Purchase order and supplier projections: `[projection names]` | Example: Dedicated service account `[account name]` with one read-only permission set `[permission set name]`. No end-user permission sets granted. | Example: `[IAM client / method as configured]` | Example: Procurement manager (business), customer IT lead (account) | [contact] | Example: Projections still exist and return the fields in use; service account still active | Example: Revoke the permission set, deactivate the account, stop the service. Nothing to uninstall in IFS Cloud. |
| Example: 2 | Example: Bank | Example: Payment files out, statements in | Example: Outbound and inbound | Example: See CRIM CRIM-003, CRIM-004 | [account, permission set] | [method] | Example: Finance lead | [contact] | Example: File format unchanged; test file accepted | [steps] |

 Legacy interfaces stopped at go-live: [link to the closed part of the interface register].

 ## 8. Extensions and localisations

 | Item | Type | Supplier / source | Version | Purpose | Licence or contract reference | Update dependency |
| --- | --- | --- | --- | --- | --- | --- |
| [name] | [Extension / Localisation / Partner product] | [name] | [x.y] | [text] | [ref] | [Must be updated with each release update: Yes / No] |
| Example: Country localisation for `[country]` | Example: Localisation | [source] | [x.y] | Example: Statutory reporting and tax handling for the legal entity in `[country]` | [ref] | [Yes / No] |

 ## 9. Delivery schedule and readiness

 | Delivery | Content | Planned | Status | Readiness for support | Owner |
| --- | --- | --- | --- | --- | --- |
| [Go-live scope per site or module, later rollouts, outstanding CRIM deliveries] | [text] | [YYYY-MM-DD] | [Live / Planned / In build] | [Handed over / Stays with project until: date] | [name] |
| Example: Site `[site]`, distribution and procurement | Example: All in-scope processes | [YYYY-MM-DD] | Live | Handed over | Supplier PM |

 Work that stays with the project team after this handover: [list with end dates]. Rule for routing cases during the overlap: [text].

 ## 10. Basic data to adjust after go-live

 Settings deliberately set for cutover or the first period of use, which someone must change later. If nobody owns them, they stay wrong.

 | # | Basic data / setting | Current value and why | Target value | When | Owner | Done |
| --- | --- | --- | --- | --- | --- | --- |
| [n] | [setting] | [text] | [text] | [date or trigger] | [name] | [ ] |
| Example: 1 | Example: Authorisation limits for purchase orders | Example: Set high for the first period so that approvals do not stop purchasing while approvers learn the process | Example: Limits from the approved procurement policy | [YYYY-MM-DD] | Example: Procurement manager | [ ] |
| Example: 2 | Example: Users with temporary extra permission sets granted for go-live support | Example: Expert users hold wider access during the support period | Example: Role-based permission sets only | [YYYY-MM-DD] | Example: Security lead | [ ] |

 ## 11. Known issues and workarounds

 | ID | Description | Area | Workaround in use | Case reference | Owner | Planned fix |
| --- | --- | --- | --- | --- | --- | --- |
| [ID] | [text] | [area] | [text] | [ref] | [name] | [Delivery, service update or date] |
| Example: R-006 | Example: Supplier order report shows the custom project code only on the first page | Example: Procurement | Example: Purchasers add the code to the order note for multi-page orders | [ref] | [name] | [delivery] |

 Open support cases with the software vendor at handover: [list or link]. Residual issues from the closure document: [link to template [IDK-24](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/24-project-closure-and-lessons-learned), section 4].

 ## 12. Handover meeting record

 | Field | Value |
| --- | --- |
| Date | [YYYY-MM-DD] |
| Attendees, project team | [names] |
| Attendees, support | [names] |
| Attendees, customer | [names] |
| Recording | [link] |
| Agenda | [Customer and solution overview; CRIM walkthrough; integrations; environments and delivery route; known issues; basic data to adjust; questions from support] |

 | # | Question or action from the meeting | Owner | Due | Closed |
| --- | --- | --- | --- | --- |
| [n] | [text] | [name] | [YYYY-MM-DD] | [ ] |

 Support start date: [YYYY-MM-DD]. From this date cases go to: [channel].

 ## Approval

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Supplier project manager (owner) | [name] | [Submitted] | [YYYY-MM-DD] |   |
| Technical solution manager | [name] | [Confirms sections 5 to 8] | [YYYY-MM-DD] |   |
| Support manager | [name] | [Accepted / Accepted with open items / Rejected] | [YYYY-MM-DD] |   |
| Customer project manager | [name] | [Accepted / Rejected] | [YYYY-MM-DD] |   |
| Customer system owner | [name] | [Accepted / Rejected] | [YYYY-MM-DD] |   |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/22-handover-to-support.md)

## Go-Live Readiness Decision Template (IDK-21)

Template IDK-21, version 1.0. Phase: Implement Solution.

 ## How to use this template

 
- This is the paper the steering group reads before it authorises go-live. Send it in advance, not on the day.
- Every criterion needs evidence that someone can open and read: a signed report, a log, a list. "We believe so" is not evidence.
- Area owners fill in their own status. The project managers challenge it. The steering group decides.
- Rows marked `Example:` show the expected level of detail. Delete them from your working copy.
- Three outcomes are possible: go, go with conditions, no-go. A no-go taken on evidence is a sound decision. Record it with the same care as a go.

 | Field | Value |
| --- | --- |
| Template ID | IDK-21 |
| Phase | Implement Solution |
| Owner | Customer project manager |
| Approver | Steering group |
| Qualification gate | Go Live Authorised |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Summary for the steering group](#1-summary-for-the-steering-group)
- [2. Readiness criteria by area](#2-readiness-criteria-by-area)
- [3. Open items](#3-open-items)
- [4. Timing considerations](#4-timing-considerations)
- [5. Decision record](#5-decision-record)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Customer | [Legal entity] |
| Go-live scope | [Companies, sites, processes] |
| Proposed go-live date | [YYYY-MM-DD] |
| Decision meeting date | [YYYY-MM-DD] |
| Document owner | [Name, customer project manager] |
| Status | [Draft / Submitted / Decided] |
| Version | [x.y] |
| Storage location | [Link] |
| Related documents | [SAT and ORT sign-off (template [IDK-18](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/18-sat-ort-test-script-and-signoff)), training record (template [IDK-19](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/19-training-plan-and-course-description)), cutover plan (template [IDK-20](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/20-cutover-plan-checklist-and-contingency)), handover to support (template [IDK-22](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/22-handover-to-support))] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| [0.1] | [YYYY-MM-DD] | [name] | [First draft] |

 ## 1. Summary for the steering group

 | Item | Value |
| --- | --- |
| Recommendation of the project managers | [Go / Go with conditions / No-go] |
| Areas ready | [list] |
| Areas ready with conditions | [list] |
| Areas not ready | [list] |
| Main remaining risk | [One sentence] |
| Decision needed by | [date, because: reason] |

 Status legend used below: Ready / Ready with conditions / Not ready / Not applicable.

 ## 2. Readiness criteria by area

 
### 2.1 Solution

 | # | Criterion | Evidence | Owner | Status |
| --- | --- | --- | --- | --- |
| S1 | SAT completed, documented and approved by the steering group | [Link to SAT completion report] | [Test lead] |   |
| S2 | All CRIM objects delivered to production and tested | [CRIM log with status] | [Supplier PM] |   |
| S3 | No open defect that blocks deployment | [Defect log filter] | [Test lead] |   |
| S4 | Production functional and technical configuration complete and matches the accepted baseline | [Configuration checklist] | [Solution architect] |   |
| S5 | Load test signed off, if required by the test strategy | [Report or "Not required" decision] | [Customer IT lead] |   |
| Example: S2 | Example: Custom fields on purchase order line, supplier order report layout and bank payment file format are in production at the version tested in SAT | Example: Handover to Support (template [IDK-22](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/22-handover-to-support)), section 6, production version per CRIM object | Example: Supplier PM | Example: Ready |

 
### 2.2 Data

 | # | Criterion | Evidence | Owner | Status |
| --- | --- | --- | --- | --- |
| D1 | Migration routines validated with full volumes | [Rehearsal log] | [Data migration lead] |   |
| D2 | Each data set validated and signed by its data owner in the latest load | [Validation sign-offs] | [Data owners] |   |
| D3 | Cleansing of legacy data complete or remaining work accepted | [Cleansing tracker] | [Data owners] |   |
| D4 | Reconciliation method for balances agreed with finance | [Reconciliation procedure] | [Finance lead] |   |
| D5 | Manual data entry tasks planned with owners and time | [Cutover checklist] | [Cutover manager] |   |

 
### 2.3 Users and training

 | # | Criterion | Evidence | Owner | Status |
| --- | --- | --- | --- | --- |
| U1 | ORT completed; expert users signed the confirmation statement | [Link to ORT statement] | [Test lead] |   |
| U2 | End-user training delivered; absentees have a catch-up date before go-live | [Attendance record] | [Training lead] |   |
| U3 | Step-by-step guides final and available to all users | [Guide library link] | [Training lead] |   |
| U4 | Expert users named per site and area, and known to users | [Expert user list] | [Customer PM] |   |

 
### 2.4 Security

 | # | Criterion | Evidence | Owner | Status |
| --- | --- | --- | --- | --- |
| X1 | Roles and permission sets built and tested with role-based logins | [Role matrix, SAT evidence] | [Security lead] |   |
| X2 | Users attached to roles in production | [User and permission set export] | [Security lead] |   |
| X3 | Segregation of duties conflicts reviewed and accepted | [Review record] | [Finance lead, auditor contact] |   |
| X4 | Project and consultant accounts reviewed; elevated access has an end date | [Account list] | [Customer IT lead] |   |
| X5 | Integration and service accounts hold only the access they need | [Account list with permission sets] | [Integration lead] |   |

 
### 2.5 Infrastructure and environments

 | # | Criterion | Evidence | Owner | Status |
| --- | --- | --- | --- | --- |
| I1 | Production environment at the agreed release and service update level | [Environment record] | [Customer IT lead] |   |
| I2 | Network access, single sign-on and identity provider tested from every site | [Test record per site] | [Customer IT lead] |   |
| I3 | Printers, label printers, scanners and mobile devices tested at each site | [Device checklist] | [Site leads] |   |
| I4 | Backup before release to users arranged and confirmed | [Cutover plan section 11] | [Customer IT lead] |   |
| I5 | Update freeze agreed around go-live | [Update strategy (template [IDK-23](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/23-update-strategy-evergreen))] | [Customer IT lead] |   |

 
### 2.6 Integrations

 | # | Criterion | Evidence | Owner | Status |
| --- | --- | --- | --- | --- |
| N1 | Every interface in the interface register tested end to end with the external party | [Interface register with test status] | [Integration lead] |   |
| N2 | Production endpoints, certificates and credentials in place and verified | [Checklist] | [Integration lead] |   |
| N3 | Monitoring and error handling for each interface has a named owner | [Interface register] | [Integration lead] |   |
| N4 | Legacy interfaces to be stopped are listed in the cutover checklist | [Cutover checklist] | [Cutover manager] |   |
| Example: N1 | Example: Bank payment file accepted by the bank in its test channel; supplier order output received and confirmed by the pilot suppliers | Example: Interface register, column "External confirmation" | Example: Integration lead | Example: Ready with conditions |

 
### 2.7 Cutover

 | # | Criterion | Evidence | Owner | Status |
| --- | --- | --- | --- | --- |
| C1 | Cutover plan and checklist approved | [Link] | [Cutover manager] |   |
| C2 | Full-volume rehearsal completed; durations fit the available window | [Rehearsal log] | [Cutover manager] |   |
| C3 | Contingency plan approved; point of no return and decision maker named | [Cutover plan section 9] | [Cutover manager] |   |
| C4 | Cutover team confirmed available, including backups | [Cutover organisation table] | [Both PMs] |   |
| C5 | Communications to users, business, suppliers and customers scheduled | [Cutover plan section 6] | [Customer PM] |   |

 
### 2.8 Support

 | # | Criterion | Evidence | Owner | Status |
| --- | --- | --- | --- | --- |
| P1 | Go-live support resourced on site for the agreed period | [Resource plan] | [Supplier PM] |   |
| P2 | Issue logging and triage process for the go-live period agreed | [Cutover plan section 8] | [Customer PM] |   |
| P3 | Service desk trained in basic administration | [Training record] | [Customer IT lead] |   |
| P4 | Handover to support scheduled | [Template [IDK-22](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/22-handover-to-support), planned date] | [Supplier PM] |   |

 
### 2.9 Business readiness

 | # | Criterion | Evidence | Owner | Status |
| --- | --- | --- | --- | --- |
| B1 | Line managers confirm their teams are staffed for go-live and the period after | [Confirmations] | [Business leads] |   |
| B2 | Changed policies and procedures published | [Procedure list] | [Change lead] |   |
| B3 | Organisation changes linked to the new processes in effect | [Change plan] | [Change lead] |   |
| B4 | Manual procedures for the freeze period known to the affected teams | [Cutover plan section 2] | [Business leads] |   |
| B5 | Sponsor and steering group members visible to the business during go-live | [Communication plan] | [Sponsor] |   |

 ## 3. Open items

 | # | Area | Item | Impact if not closed | Owner | Due | Needed before go-live |
| --- | --- | --- | --- | --- | --- | --- |
| [n] | [area] | [text] | [text] | [name] | [YYYY-MM-DD] | [Yes / No] |
| Example: 4 | Example: Integrations | Example: One pilot supplier has not confirmed receipt of the new order format | Example: Orders to this supplier sent manually by email until confirmed | Example: Procurement manager | [YYYY-MM-DD] | Example: No, workaround accepted |

 ## 4. Timing considerations

 | Consideration | Assessment | Conclusion |
| --- | --- | --- |
| Business peaks | [Seasonal peaks, campaigns, large deliveries around the proposed date] | [OK / Conflict: text] |
| Holidays and absences | [Public holidays per country, school holidays, planned absence of key people on both sides] | [OK / Conflict: text] |
| Financial period | [Period or year end, closing activities, opening balances, audit dates] | [OK / Conflict: text] |
| External parties | [Bank, authority or partner deadlines; supplier and customer shutdowns] | [OK / Conflict: text] |
| Update calendar | [Planned service or release update near go-live] | [OK / Conflict: text] |
| Competing projects | [Other changes landing on the same users] | [OK / Conflict: text] |
| Fallback date | [Next possible date if this one is missed, and what it costs] | [YYYY-MM-DD] |

 ## 5. Decision record

 | Field | Value |
| --- | --- |
| Meeting date | [YYYY-MM-DD] |
| Present | [names, roles] |
| Papers sent in advance on | [YYYY-MM-DD] |
| Decision | [Go / Go with conditions / No-go] |
| Go-live date confirmed | [YYYY-MM-DD] |
| Reason for the decision | [text] |

 Conditions (for "go with conditions"):

 | # | Condition | Owner | Must be met by | Verified by | If not met |
| --- | --- | --- | --- | --- | --- |
| [n] | [text] | [name] | [date, time] | [name] | [Go-live is postponed / Escalate to: name] |

 For a no-go:

 | Field | Value |
| --- | --- |
| Criteria not met | [IDs from section 2] |
| Actions to reach readiness | [text, owners] |
| Next decision date | [YYYY-MM-DD] |
| Communication of the postponement | [Who informs whom, by when] |

 ## Approval

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer project manager (owner) | [name] | [Submitted] | [YYYY-MM-DD] |   |
| Supplier project manager | [name] | [Recommends go / go with conditions / no-go] | [YYYY-MM-DD] |   |
| Project sponsor | [name] | [Go / Go with conditions / No-go] | [YYYY-MM-DD] |   |
| Steering group chair | [name] | [Go / Go with conditions / No-go] | [YYYY-MM-DD] |   |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/21-go-live-readiness-decision.md)

## Cutover Plan, Checklist and Contingency Template (IDK-20)

Template IDK-20, version 1.0. Phase: Implement Solution (prepared and rehearsed), Go Live (executed).

 ## How to use this template

 
- This is one document with two levels of detail. Section 2 plans the period around go-live by day. Section 3 plans the days around go-live by hour.
- Draft both before the first rehearsal. Durations in sections 3 and 5 must come from a rehearsal with full data volumes, never from an estimate. Rehearse more than once.
- During the cutover this is a live document. The cutover manager updates actual times as tasks finish and reviews status in short, frequent meetings.
- Rows marked `Example:` show the expected level of detail. Delete them from your working copy.
- The contingency plan (section 9) is approved together with the plan. A cutover without a written way back is not ready for the gate.

 | Field | Value |
| --- | --- |
| Template ID | IDK-20 |
| Phase | Implement Solution (prepared and rehearsed), Go Live (executed) |
| Owner | Cutover manager |
| Approver | Steering group |
| Qualification gate | Go Live Authorised |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Cutover organisation](#1-cutover-organisation)
- [2. Cutover plan (day granularity)](#2-cutover-plan-day-granularity)
- [3. Cutover checklist (hour granularity)](#3-cutover-checklist-hour-granularity)
- [4. Time-critical configuration switches](#4-time-critical-configuration-switches)
- [5. Data migration run order](#5-data-migration-run-order)
- [6. Communications](#6-communications)
- [7. Legacy decommissioning](#7-legacy-decommissioning)
- [8. Support arrangements](#8-support-arrangements)
- [9. Contingency plan](#9-contingency-plan)
- [10. Rehearsal log](#10-rehearsal-log)
- [11. Backup before release to users](#11-backup-before-release-to-users)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Customer | [Legal entity] |
| Go-live scope | [Companies, sites, processes] |
| Planned go-live date | [YYYY-MM-DD] |
| Document owner | [Name, cutover manager] |
| Status | [Draft / Rehearsed / Approved / In execution / Closed] |
| Version | [x.y] |
| Storage location | [Link. Also keep an offline copy during the cutover.] |
| Related documents | [Data migration plan, go-live readiness decision (template [IDK-21](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/21-go-live-readiness-decision)), communication plan, legacy decommissioning strategy, handover to support (template [IDK-22](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/22-handover-to-support))] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| [0.1] | [YYYY-MM-DD] | [name] | [First draft] |

 ## 1. Cutover organisation

 | Role | Name | Contact during cutover | Backup |
| --- | --- | --- | --- |
| Cutover manager | [name] | [phone] | [name] |
| Customer project manager | [name] | [phone] | [name] |
| Supplier project manager | [name] | [phone] | [name] |
| Data migration lead | [name] | [phone] | [name] |
| Technical lead, environments | [name] | [phone] | [name] |
| Integration lead | [name] | [phone] | [name] |
| Business validation leads per area | [names] | [phone] | [names] |
| Decision maker for go / rollback | [name, role] | [phone] | [name] |

 Status reviews during cutover: [times, channel, attendees]. Decision rule when the decision maker cannot be reached: [text].

 ## 2. Cutover plan (day granularity)

 Workstreams: data migration, configuration switches, communications, legacy decommissioning, support arrangements, infrastructure, business preparation.

 | ID | Day | Workstream | Task | Owner | Depends on | Planned | Actual | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [ID] | [YYYY-MM-DD] | [workstream] | [task] | [name] | [ID] | [YYYY-MM-DD] | [YYYY-MM-DD] | [Not started / In progress / Done / Late] |
| Example: C-012 | [YYYY-MM-DD] | Example: Business preparation | Example: Stop creating new purchase orders in legacy; urgent buys recorded on the agreed manual form for entry after go-live | Example: Procurement manager | Example: C-008 supplier notice sent | [YYYY-MM-DD] |   | Not started |
| Example: C-015 | [YYYY-MM-DD] | Example: Data migration | Example: Final extract of supplier, customer and part master data from legacy; control totals recorded | Example: Data migration lead | Example: C-012, C-013 | [YYYY-MM-DD] |   | Not started |

 Business freeze periods:

 | Process | Freeze starts | Freeze ends | Manual procedure during freeze | Owner |
| --- | --- | --- | --- | --- |
| [Process] | [date, time] | [date, time] | [text or link] | [name] |

 ## 3. Cutover checklist (hour granularity)

 | Seq | Planned start | Planned end | Task | Owner | Predecessor | Checkpoint | Actual start | Actual end | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [n] | [day, hh:mm] | [day, hh:mm] | [task] | [name] | [Seq] | [None / Go-no-go / Point of no return] |   |   |   |
| Example: 14 | [day, hh:mm] | [day, hh:mm] | Example: Set legacy to read-only for order entry, purchasing and inventory transactions | Example: Legacy system administrator | Example: 13 | None |   |   |   |
| Example: 15 | [day, hh:mm] | [day, hh:mm] | Example: Run Data Migration Manager jobs for open purchase orders; compare loaded line count and value with extract control totals | Example: Data migration lead, procurement validation lead | Example: 14 | Go-no-go |   |   |   |

 Rules for the checklist:

 
- Every task has one named owner who is present or reachable at the planned time.
- Every planned duration is the longest duration seen in rehearsal, plus the buffer agreed in the project: [agree in project].
- A task is done when its owner reports it to the cutover manager. Not before.

 ## 4. Time-critical configuration switches

 Settings that must stay off until a precise moment, or be changed at a precise moment.

 | # | Switch | Environment | From | To | When (checklist seq) | Owner | Verified by |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [n] | [setting] | [Production] | [state] | [state] | [Seq] | [name] | [name] |
| Example: 1 | Example: Scheduled background jobs for order processing and planning | Production | Example: Inactive | Example: Active with production schedule | [Seq] | Example: Technical lead | Example: Supply chain lead |
| Example: 2 | Example: Integration routing to external parties (supplier order output, bank files) | Production | Example: Test endpoints or disabled | Example: Production endpoints | [Seq] | Example: Integration lead | Example: Finance lead |
| [n] | [Workflows and event actions that send email to suppliers or customers] |   |   |   |   |   |   |
| [n] | [Number series start values] |   |   |   |   |   |   |
| [n] | [Accounting periods opened for user groups] |   |   |   |   |   |   |
| [n] | [End users activated and attached to production permission sets] |   |   |   |   |   |   |

 ## 5. Data migration run order

 Data Migration Manager loads through standard business logic. Invalid records are rejected at load, so the order matters and every load needs a reject check.

 | Order | Data set | Method | Source | Depends on | Duration in rehearsal | Planned duration | Validation | Validated by |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [n] | [data set] | [Data Migration Manager / Copy and paste / Manual entry] | [system, file] | [Order no.] | [from rehearsal log] | [from rehearsal log plus buffer] | [Control totals, record count, spot check] | [name] |
| Example: 3 | Example: Suppliers with addresses, payment terms and purchase part links | Example: Data Migration Manager | Example: Legacy extract file `[name]` | Example: 1 basic data, 2 parts | [from rehearsal log] | [from rehearsal log plus buffer] | Example: Record count equals extract; reject list empty or each reject explained; spot check by purchasers | Example: Procurement lead |
| Example: 7 | Example: Inventory on hand per location | Example: Data Migration Manager | Example: Legacy stock count extract after final count | Example: 2 parts, 5 locations | [from rehearsal log] | [from rehearsal log plus buffer] | Example: Quantity and value per site equal legacy stock report | Example: Inventory lead, finance lead |

 Reject handling: [who reviews rejects, who corrects source data, how a reload is approved].

 ## 6. Communications

 | Audience | Message | Sender | Channel | When | Feedback route | Done |
| --- | --- | --- | --- | --- | --- | --- |
| Project team | [Cutover schedule, roles, status meeting times, contact list] | [Cutover manager] | [channel] | [YYYY-MM-DD] | [channel] | [ ] |
| Users | [Freeze dates, first login instructions, where to get help, where the guides are] | [Customer PM] | [channel] | [YYYY-MM-DD] | [Expert users] | [ ] |
| Business and management | [Go-live decision, expected disruption, status updates during cutover, confirmation of go-live] | [Sponsor] | [channel] | [YYYY-MM-DD] | [Steering group] | [ ] |
| Suppliers | [New document layouts, changed order numbers, ordering pause, contact for questions] | [Procurement manager] | [channel] | [YYYY-MM-DD] | [mailbox] | [ ] |
| Customers | [Delivery and invoicing pause, changed document layouts, contact for questions] | [Sales manager] | [channel] | [YYYY-MM-DD] | [mailbox] | [ ] |
| Example: Suppliers | Example: No purchase orders will be issued between `[YYYY-MM-DD]` and `[YYYY-MM-DD]`. Orders after that carry a new number format. Confirmations go to `[address]`. | Example: Procurement manager | Example: Email to supplier contacts from the migrated supplier master | [YYYY-MM-DD] | Example: Procurement mailbox | [ ] |

 ## 7. Legacy decommissioning

 | System / interface | Action at go-live | Action later | Data retention need | Owner | Date |
| --- | --- | --- | --- | --- | --- |
| [system] | [Read-only / Stopped / Runs in parallel for: reason] | [Archive / Switch off / Contract end] | [Legal or audit requirement] | [name] | [YYYY-MM-DD] |
| Example: Legacy ERP | Example: Read-only for all users at checklist seq `[n]` | Example: Archive and switch off after the period in the decommissioning strategy | Example: Financial records per local law | Example: IT manager | [YYYY-MM-DD] |

 Legacy interfaces to stop: [list from the interface register with owner and checklist seq].

 ## 8. Support arrangements

 | Item | Arrangement |
| --- | --- |
| First-line contact | Expert users per site and area: [link to list] |
| Second line | [Core team, location, hours] |
| Supplier go-live support | [Who, on site or remote, period: agree in project] |
| Issue logging | [Tool, who may log, triage time] |
| Floor walking | [Schedule per site] |
| Service desk | [Trained in basic administration: Yes / No. Scope: password, user activation, printer routing.] |
| Status meetings after go-live | [Frequency and length: agree in project] |
| Transition to regular support | [Date, see handover to support (template [IDK-22](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/22-handover-to-support))] |

 ## 9. Contingency plan

 
### 9.1 Triggers

 | Trigger | Measured how | Decision |
| --- | --- | --- |
| [Condition that makes continuing unsafe] | [evidence] | [Pause / Rollback / Continue with workaround] |
| Example: Inventory balances do not reconcile with legacy after reload | Example: Value per site against legacy stock report | Example: Pause at go-no-go checkpoint; rollback if not resolved before the point of no return |

 
### 9.2 Point of no return

 | Item | Value |
| --- | --- |
| Definition | [The checklist step after which legacy can no longer be reinstated without losing or re-entering business transactions] |
| Checklist seq | [Seq] |
| Planned time | [day, hh:mm] |
| Decision maker | [name, role] |
| Inputs to the decision | [Data validation sign-offs, switch verification, open issues] |
| After this point | Problems are fixed forward in IFS Cloud. Section 9.3 no longer applies. |

 
### 9.3 Rollback steps

 | Step | Action | Owner | Planned duration | Verified by |
| --- | --- | --- | --- | --- |
| 1 | [Announce rollback decision to team and management] | [Cutover manager] | [from rehearsal] |   |
| 2 | [Deactivate end users and background jobs in IFS Cloud production] | [Technical lead] | [from rehearsal] |   |
| 3 | [Stop production integration routing; restore legacy interfaces] | [Integration lead] | [from rehearsal] |   |
| 4 | [Remove read-only state from legacy; confirm legacy data is as at freeze] | [Legacy administrator] | [from rehearsal] |   |
| 5 | [Enter transactions recorded manually during the freeze into legacy] | [Business leads] | [from rehearsal] |   |
| 6 | [Inform users, business, suppliers and customers] | [Customer PM, sponsor] |   |   |
| 7 | [Schedule review and new go-live decision] | [Steering group] |   |   |

 Rollback has been rehearsed: [Yes / No, date, result].

 ## 10. Rehearsal log

 | Rehearsal | Date | Environment | Data volume | Completed |
| --- | --- | --- | --- | --- |
| [n] | [YYYY-MM-DD] | [name] | [Full / Partial: reason] | [Yes / No] |

 | Rehearsal | Task (seq) | Planned duration | Actual duration | Why it took longer or failed | Change made to the plan | Owner |
| --- | --- | --- | --- | --- | --- | --- |
| [n] | [Seq] | [value] | [value] | [reason] | [change] | [name] |
| Example: [n] | Example: 15, open purchase orders load | [value] | [value] | Example: Rejects caused by suppliers missing purchase part links; reload needed | Example: Add pre-load check query on part links to seq 12; move supplier validation earlier | Example: Data migration lead |

 Decision after rehearsal: [Plan accepted / Another rehearsal required on: date]. Decided by: [name].

 ## 11. Backup before release to users

 | Item | Value |
| --- | --- |
| What is backed up | [Production database and file storage after final data validation, before user activation] |
| Requested from | [Cloud service provider / Customer IT: procedure reference] |
| Checklist seq | [Seq, directly before user activation] |
| Confirmed by | [name] |
| Confirmation reference | [ticket or log entry] |
| Restore responsibility and procedure | [name, link] |

 Users are not released until the backup is confirmed.

 ## Approval

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Cutover manager (owner) | [name] | [Submitted] | [YYYY-MM-DD] |   |
| Customer project manager | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |
| Supplier project manager | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |
| Customer IT lead | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |
| Steering group chair | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/20-cutover-plan-checklist-and-contingency.md)

## Training Plan and Course Description Template (IDK-19)

Template IDK-19, version 1.0. Phase: Establish Solution (prepared), Implement Solution (delivered).

 ## How to use this template

 
- Part A is the training plan: one per project. Part B is a course description: copy it once per course in the catalogue.
- Write the training strategy summary first. Material is built only after the strategy is agreed.
- Build courses around business roles, not around modules. A role-based course can be reused for new joiners and for later rollouts.
- Rows marked `Example:` show the expected level of detail. Delete them from your working copy.
- The goal is that [Customer] can train its own people without outside help. Check every decision in this document against that goal.

 | Field | Value |
| --- | --- |
| Template ID | IDK-19 |
| Phase | Establish Solution (prepared), Implement Solution (delivered) |
| Owner | Customer training lead |
| Approver | Customer project manager |
| Qualification gate | Solution Established (plan approved), Go Live Authorised (training delivered) |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [Part A. Training plan](#part-a-training-plan)
- [Part B. Course description](#part-b-course-description)
- [Part C. Attendance and evaluation record](#part-c-attendance-and-evaluation-record)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Customer | [Legal entity] |
| Document owner | [Name, customer training lead] |
| Status | [Draft / In review / Approved] |
| Version | [x.y] |
| Storage location | [Link] |
| Related documents | [Training strategy, role matrix, step-by-step guides, test strategy (template [IDK-17](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/17-test-strategy)), cutover plan (template [IDK-20](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/20-cutover-plan-checklist-and-contingency))] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| [0.1] | [YYYY-MM-DD] | [name] | [First draft] |

 ## Part A. Training plan

 
### 1. Training strategy summary

 | Question | Answer |
| --- | --- |
| What is the training goal? | [Customer self-sufficiency: internal trainers, reusable material, expert users as first-line contact] |
| Who trains the core team? | [Supplier application consultants] |
| Who trains expert users? | [Core team members who attended train-the-trainer] |
| Who trains end users? | [Internal expert users] |
| When are end users trained? | [As close to go-live as practical; window: agree in project] |
| In which environment? | [Training environment name, data set, refresh rule] |
| Which languages? | [list] |
| How is attendance enforced? | [Line manager commitment; access to production only after attendance: Yes / No] |
| How is effectiveness checked? | [Evaluation per course; ORT confirmation by expert users] |

 
### 2. Audiences and roles

 | Audience | Who they are | What they need | Trained by | When |
| --- | --- | --- | --- | --- |
| Core team | [Functional team members] | Broad view of the solution and how areas integrate; depth in their own area | Supplier consultants | [Establish Solution] |
| Technical team | [Technical analysts, administrators] | [Administration and configuration, permission sets, Data Migration Manager, lobby configuration, custom objects, Business Process Automation, report design, integration configuration, Build Place] | Supplier technical resources | [Establish Solution] |
| Expert users | [Named per site and area] | Full role-based courses plus support skills | Core team trainers | [Implement Solution, before ORT] |
| End users | [By business role] | Only what their role does, in their own terms | Expert users | [Implement Solution, close to go-live] |
| Managers | [Line managers, approvers] | Approvals, lobbies, what changes for their teams | [Core team] | [agree in project] |
| Service desk | [names] | Basic administration, user and permission set handling, where to find guides | [Technical team] | [Before go-live] |

 Rule for the core team: attend courses outside your own area. Someone from the technical team attends the functional courses, so that one person understands both sides.

 Business role to course mapping:

 | Business role | Permission set(s) | Courses required | Headcount | Sites |
| --- | --- | --- | --- | --- |
| [Role] | [names] | [Course IDs] | [n] | [sites] |
| Example: Purchaser | Example: `[PS_PURCHASER]` | Example: GEN-01, PUR-01, PUR-02 | [n] | [sites] |

 
### 3. Delivery methods

 | Method | Used for | Notes |
| --- | --- | --- |
| Classroom, hands-on in the training environment | [Role-based end-user courses] | Short sessions, small groups: [group size and session length: agree in project] |
| Remote live session | [Sites without a local trainer] | [Tool, recording rule] |
| Recording | [Concept introductions, refreshers, new joiners] | [Storage location] |
| Step-by-step guide, self-study | [Low-frequency tasks] | [Guide library link] |
| Floor walking after go-live | [All sites] | [Expert users, schedule in cutover plan] |

 
### 4. Train-the-trainer

 | Item | Agreement |
| --- | --- |
| Who becomes a trainer | [Names, area, site] |
| Train-the-trainer session | [Date, led by, content: adult teaching basics, instructor flow walkthrough, handling questions, resetting data sets] |
| Rule | Nobody delivers a course before attending train-the-trainer and sitting the course as a participant. |
| Multi-site approach | [Which sites are trained first; influential sites are involved early so that they carry the message to others] |
| Trainer backup | [Second trainer per course] |

 
### 5. Course catalogue

 | Course ID | Course name | Audience / role | Format | Length | Trainer | Guides used | Status of material |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [ID] | [name] | [role] | [method] | [agree in project] | [name] | [guide names] | [Not started / Draft / Tested with expert users / Final] |
| Example: GEN-01 | Example: Finding your way in IFS Cloud: navigation, search, lobbies, saved searches, attachments | Example: All users | Example: Classroom | [agree in project] | [name] | Example: Navigation basics | Draft |
| Example: PUR-01 | Example: From requisition to released purchase order | Example: Purchaser | Example: Classroom, hands-on | [agree in project] | [name] | Example: Create requisition; Convert to order; Send order | Draft |

 
### 6. Schedule with attendees

 | Session ID | Course ID | Date and time | Location / link | Trainer | Attendees | Line manager informed | Environment booked |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [ID] | [ID] | [date, time] | [room / link] | [name] | [names or link to list] | [Yes / No] | [Yes / No] |
| Example: S-031 | Example: PUR-01 | [date, time] | [room] | [name] | [names] | Yes | Yes |

 Scheduling rules:

 
- Expert users are trained first. Their sessions are also the test of the material. Corrections are made before end-user sessions start.
- End-user sessions run [as close to go-live as practical; window: agree in project].
- Catch-up sessions for absentees: [dates].
- The training environment is refreshed with the data set on [dates], by [name].

 
### 7. Risks

 | Risk | Mitigation | Owner |
| --- | --- | --- |
| Users not released for training | [Sessions agreed with line managers; attendance reported to the steering group] | [Customer PM] |
| Training too early, knowledge fades before go-live | [Refresher recordings; floor walking] | [Training lead] |
| [Risk] | [Mitigation] | [name] |

 ## Part B. Course description

 
### B1. Course header

 | Field | Value |
| --- | --- |
| Course ID and name | [ID, name] |
| Version | [x.y] |
| Course owner | [name] |
| Objective | [After this course the participant can ..., without help, using the step-by-step guide] |
| Audience | [Business role(s)] |
| Prerequisites | [Courses attended; user account and permission set active in the training environment] |
| Length | [agree in project] |
| Group size | [agree in project] |
| Format | [Classroom / remote / blended] |

 Example objective: After this course a purchaser can create a requisition, turn it into a purchase order, send it to the supplier and register the supplier's confirmation, including a changed delivery date.

 
### B2. Agenda

 | # | Topic | Type | Guide used |
| --- | --- | --- | --- |
| 1 | [Topic] | [Concept / Demo / Exercise / Review] | [Guide name] |
| Example: 1 | Example: Why the process changes and what it means for a purchaser | Example: Concept | None |
| Example: 2 | Example: Create and release a purchase requisition | Example: Demo, then exercise | Example: Create requisition |

 Start every course with what changes for this role and what the participant gains. Screens come second.

 
### B3. Instructor flow

 | # | Trainer does | Trainer says (key points) | Participants do | Watch out for |
| --- | --- | --- | --- | --- |
| 1 | [action] | [points] | [action] | [typical mistake, typical question] |
| Example: 2 | Example: Shows the Purchase Requisition page, creates one line, releases it | Example: The supplier and price come from the supplier for purchase part record. If they are missing, this is a data issue to report, not something to type over. | Example: Repeat with their own part from the data set sheet | Example: Users pick the wrong site. Ask them to check the site field first. |

 
### B4. Data set

 | Item | Value |
| --- | --- |
| Training environment | [name] |
| Data set name and version | [name] |
| Data per participant | [Own parts, suppliers, customers, so that exercises do not collide] |
| Reset procedure | [How the data set is restored between sessions, by whom] |
| Logins | [Role-based training users with production permission sets] |

 | Participant no. | Login | Part | Supplier | Site |
| --- | --- | --- | --- | --- |
| Example: P01 | Example: `[TRN_PUR_01]` | `[part no]` | `[supplier ID]` | `[site]` |

 
### B5. Step-by-step guides used

 | Guide | Version | Verified in SAT | Location |
| --- | --- | --- | --- |
| [name] | [x.y] | [Yes / No] | [link] |

 Guides are written in the language of the end user. If a guide is wrong, the trainer reports it to [name] the same day.

 
### B6. Homework

 | Task | Done where | Checked by |
| --- | --- | --- |
| [Task the participant repeats alone after the session] | [Training environment] | [Expert user] |
| Example: Create and release an order for the parts you buy most often, using only the guide | Training environment | Expert user for procurement |

 
### B7. Evaluation

 | Question | How measured |
| --- | --- |
| Can the participant do the task alone? | [Practical check at the end of the session: task, pass rule] |
| Was the course useful? | [Feedback form: link] |
| What must change in the material? | [Trainer notes after each session] |

 ## Part C. Attendance and evaluation record

 | Session ID | Participant | Role | Attended | Practical check | Follow-up needed | Trainer |
| --- | --- | --- | --- | --- | --- | --- |
| [ID] | [name] | [role] | [Yes / No] | [Pass / Repeat] | [None / text] | [name] |
| Example: S-031 | [name] | Purchaser | Yes | Pass | None | [name] |

 Summary for the gate:

 | Measure | Value |
| --- | --- |
| Users planned for training | [n] |
| Users trained | [n] |
| Users outstanding, with catch-up date | [n, date] |
| Users attached to roles in production | [Yes / No] |
| Material corrections open | [n, owner] |

 ## Approval

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer training lead (owner) | [name] | [Submitted] | [YYYY-MM-DD] |   |
| Customer project manager | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |
| Supplier project manager | [name] | [Reviewed] | [YYYY-MM-DD] |   |
| Steering group chair (end-user training complete) | [name] | [Confirmed] | [YYYY-MM-DD] |   |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/19-training-plan-and-course-description.md)

## SAT and ORT Test Script and Sign-off Template (IDK-18)

Template IDK-18, version 1.0. Phase: Establish Solution (SAT), Implement Solution (ORT).

 ## How to use this template

 
- Part A is one scenario script. Copy it once per scenario. Parts B to E exist once per test cycle.
- Write scripts for the Solution Acceptance Test (SAT). Reuse the same scripts, unchanged, for the Operational Readiness Test (ORT). The difference is who runs them: functional teams in SAT, expert users in ORT with the core team advising only.
- Run every script with the end-user login and permission set named in the header. A pass under an administrator account proves nothing.
- Fill in the expected result before execution. Fill in the actual result on the day of execution.
- Rows marked `Example:` show the expected level of detail. Delete them from your working copy.

 | Field | Value |
| --- | --- |
| Template ID | IDK-18 |
| Phase | Establish Solution (SAT), Implement Solution (ORT) |
| Owner | Customer test lead |
| Approver | Steering group |
| Qualification gate | Solution Established (SAT), Go Live Authorised (ORT) |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [Part A. Scenario script](#part-a-scenario-script)
- [Part B. Defect log](#part-b-defect-log)
- [Part C. SAT completion report](#part-c-sat-completion-report)
- [Part D. ORT confirmation statement by expert users](#part-d-ort-confirmation-statement-by-expert-users)
- [Part E. Steering group approval record](#part-e-steering-group-approval-record)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Customer | [Legal entity] |
| Test cycle | [SAT / ORT] |
| Document owner | [Name, customer test lead] |
| Status | [Draft / Approved for execution / Executed / Signed off] |
| Version | [x.y] |
| Storage location | [Link] |
| Related documents | [Test strategy (template [IDK-17](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/17-test-strategy)), process model, CRIM log, step-by-step guides] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| [0.1] | [YYYY-MM-DD] | [name] | [First draft] |

 ## Part A. Scenario script

 
### A1. Scenario header

 | Field | Value |
| --- | --- |
| Scenario ID | [Area-nn] |
| Scenario name | [Short business description] |
| End-to-end process | [Process name and link to the process model] |
| Process owner | [name] |
| Script author | [name] |
| Business role under test | [Role name as used in the business] |
| Permission set(s) | [Permission set names granted to the test login] |
| Test login | [User ID created for this role. Not a personal or administrator account.] |
| Company / site | [Company, site] |
| Environment | [Environment name] |
| CRIM objects touched | [IDs from the CRIM log] |
| Step-by-step guide(s) verified | [Guide name and version] |
| Case type | [Regular / Normal exception / Specific exception] |
| Success criteria | [What must be true at the end for the scenario to pass] |

 Example header values:

 | Field | Value |
| --- | --- |
| Example: Scenario name | Example: Purchase of an inventory part, supplier confirms a later delivery date, receipt into inspection |
| Example: Business role under test | Example: Purchaser, then Warehouse receiver |
| Example: Permission set(s) | Example: `[PS_PURCHASER]`, `[PS_WH_RECEIVER]` |
| Example: Success criteria | Example: Stock is available at the correct location, the purchase order line is closed, the receipt is ready for invoice matching |

 
### A2. Data prerequisites

 | # | Data object | Required state | Source | Verified by | OK |
| --- | --- | --- | --- | --- | --- |
| 1 | [Object] | [State] | [Migrated / Manually created / Created by earlier scenario] | [name] | [ ] |
| Example: 1 | Example: Supplier `[supplier ID]` | Example: Active, with payment terms, delivery terms and purchase part link to the test part | Example: Migrated through Data Migration Manager | Example: Procurement lead | [ ] |
| Example: 2 | Example: Inventory part `[part no]` on site `[site]` | Example: Planning data set, default receipt location defined, inspection required | Example: Migrated | Example: Inventory lead | [ ] |

 
### A3. Step table

 | Step | Page | Action | Input data | Expected result | Actual result | Pass/Fail | Defect ID |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | [Page name] | [What the user does] | [Values to enter] | [What the user must see] |   |   |   |
| Example: 1 | Example: Purchase Requisition | Example: Create a requisition with one part line and release it | Example: Part `[part no]`, quantity `[qty]`, wanted receipt date `[YYYY-MM-DD]` | Example: Requisition line has status Released. The default supplier and price are fetched. |   |   |   |
| Example: 2 | Example: Purchase Order | Example: Convert the requisition line to an order, release and send it | Example: No extra input | Example: Order status is Released. The order document is produced through the agreed output channel. |   |   |   |
| [n] |   |   |   |   |   |   |   |

 Execution record:

 | Field | Value |
| --- | --- |
| Executed by | [name] |
| Execution date | [YYYY-MM-DD] |
| Overall result | [Pass / Pass with workaround / Fail / Blocked] |
| Guide accurate | [Yes / No, corrections sent to: name] |
| Tester comment | [text] |

 
### A4. Coverage of regular and exceptional cases

 Complete this once per end-to-end process. Testing escalates from the common flow, to exceptions that happen in normal business, to exceptions specific to [Customer].

 | Process | Case | Case type | Scenario ID | Included in SAT | Included in ORT |
| --- | --- | --- | --- | --- | --- |
| [Process] | [Case] | [Regular / Normal exception / Specific exception] | [ID] | [Yes / No, reason] | [Yes / No, reason] |
| Example: Procure to pay | Example: Standard purchase of inventory part | Example: Regular | Example: P2P-01 | Yes | Yes |
| Example: Procure to pay | Example: Supplier delivers more than ordered, beyond the agreed tolerance | Example: Normal exception | Example: P2P-04 | Yes | Yes |

 Coverage check by process owner: every process in the confirmed scope has at least a regular case and the exceptions the business meets in normal operation. Confirmed by [name] on [YYYY-MM-DD].

 ## Part B. Defect log

 Classification follows the scheme in the test strategy (template [IDK-17](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/17-test-strategy), section 9).

 | Defect ID | Scenario / step | Description | Cause | Blocks deployment | Contractual | Owner side | Owner | Target date | May close after phase | Status | Retest result |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [ID] | [ID / step] | [What happened, what was expected] | [Data / User error / Application error / Wrong solution] | [Yes / No] | [Yes / No] | [Customer / Supplier] | [name] | [YYYY-MM-DD] | [Yes / No] | [Open / Fixed / Retested / Closed] |   |
| Example: D-014 | Example: P2P-01 / 2 | Example: Purchase order report prints without the custom field for the customer's internal project code | Example: Application error | No | Yes | Supplier | [name] | [YYYY-MM-DD] | No | Open |   |

 ## Part C. SAT completion report

 
### C1. Execution summary

 | Process area | Scripts planned | Executed | Passed | Passed with workaround | Failed | Blocked |
| --- | --- | --- | --- | --- | --- | --- |
| [Area] | [n] | [n] | [n] | [n] | [n] | [n] |
| Total | [n] | [n] | [n] | [n] | [n] | [n] |

 Environment used: [name, refresh date, source]. Test period: [from, to]. Testers: [list or link].

 
### C2. What the SAT had to prove

 The steering group approves the SAT on the basis of these seven statements. Each needs evidence, not opinion.

 | # | Statement | Evidence | Confirmed by | Result |
| --- | --- | --- | --- | --- |
| 1 | Every process in the agreed scope does what the business requires of it. | [Script results per process; coverage table A4] | [Process owners] | [Yes / No / With reservations] |
| 2 | The solution fits the physical operation: the way goods, people, documents and devices actually move at [Customer]. | [Scenarios run with real printers, labels, mobile devices, at real locations] | [Operations lead] |   |
| 3 | The solution as built, including every configuration, report, integration and modification, is complete and has no error that would stop operations. | [CRIM log with delivery and test status; defect log filtered on blocking items] | [Customer PM, supplier PM] |   |
| 4 | The customer team understands the solution well enough to run it and explain it. | [Scripts executed by customer testers without consultant hands on the keyboard] | [Test lead] |   |
| 5 | The migrated data is good enough to run the business on. | [Data validation sign-offs per data set; scripts run on migrated records] | [Data owners] |   |
| 6 | The step-by-step guides describe the process correctly. | [Guide accuracy field in each execution record] | [Training lead] |   |
| 7 | The roles and permission sets in the system match the roles people hold in the business. | [Role matrix; scripts run with role-based test logins] | [Security lead] |   |

 
### C3. Open items at SAT completion

 | Defect ID | Description | Blocks deployment | Agreed workaround | Owner | Target date | Accepted to close after the phase by |
| --- | --- | --- | --- | --- | --- | --- |
| [ID] | [text] | [Yes / No] | [text] | [name] | [YYYY-MM-DD] | [both PMs] |

 
### C4. Recommendation

 [Test lead's recommendation to the steering group: approve / approve with listed conditions / do not approve. State the reason in plain terms.]

 ## Part D. ORT confirmation statement by expert users

 ORT conditions:

 | Condition | Met |
| --- | --- |
| Expert users were trained before the ORT with the final training material | [Yes / No] |
| Expert users ran the SAT scripts themselves, under their own role-based logins | [Yes / No] |
| The core team advised on request and did not execute steps | [Yes / No] |
| Users are attached to roles in the ORT environment as they will be in production | [Yes / No] |

 Statement:

 
> We, the expert users named below, have run the agreed scenarios for our area in the ORT environment. On behalf of the business we confirm that the solution supports our daily work, that the training and step-by-step guides we received are sufficient, and that we are ready to act as first-line contact for our colleagues after go-live. Reservations are listed below.

 | Process area | Expert user | Site / department | Reservations | Date | Signature |
| --- | --- | --- | --- | --- | --- |
| [Area] | [name] | [site] | [None / text] | [YYYY-MM-DD] |   |
| Example: Procurement | [name] | [site] | Example: Guide for supplier invoice matching needs a section on price differences | [YYYY-MM-DD] |   |

 ## Part E. Steering group approval record

 | Field | SAT | ORT |
| --- | --- | --- |
| Meeting date | [YYYY-MM-DD] | [YYYY-MM-DD] |
| Papers sent in advance on | [YYYY-MM-DD] | [YYYY-MM-DD] |
| Documents presented | [Completion report, defect log, open items] | [Confirmation statements, defect log, open items] |
| Decision | [Approved / Approved with conditions / Not approved] | [Approved / Approved with conditions / Not approved] |
| Conditions and owners | [text] | [text] |
| Minutes reference | [link] | [link] |

 ## Approval

 | Role | Name | Cycle | Decision | Date | Signature |
| --- | --- | --- | --- | --- | --- |
| Customer test lead (owner) | [name] | [SAT / ORT] | [Submitted] | [YYYY-MM-DD] |   |
| Customer project manager | [name] | [SAT / ORT] | [Approved / Rejected] | [YYYY-MM-DD] |   |
| Supplier project manager | [name] | [SAT / ORT] | [Approved / Rejected] | [YYYY-MM-DD] |   |
| Steering group chair | [name] | [SAT / ORT] | [Approved / Rejected] | [YYYY-MM-DD] |   |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/18-sat-ort-test-script-and-signoff.md)

## Test Strategy Template (IDK-17)

Template IDK-17, version 1.0. Phase: Initiate Project (drafted), maintained through Implement Solution.

 ## How to use this template

 
- Write this document early, before any script exists. It sets the rules; the scripts (template [IDK-18](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/18-sat-ort-test-script-and-signoff)) follow them.
- Replace every bracketed field. Rows marked `Example:` show the expected level of detail; delete them before approval.
- Keep all values project specific. Where you see `[agree in project]`, the two project managers decide and record the value.
- Review the strategy at the start of every test cycle and update the cycle table if the plan has moved.
- The customer manages all testing except unit testing. If your contract says otherwise, change section 4 first and let the rest follow.

 | Field | Value |
| --- | --- |
| Template ID | IDK-17 |
| Phase | Initiate Project (drafted), maintained through Implement Solution |
| Owner | Customer test lead |
| Approver | Steering group |
| Qualification gate | Project Initiated |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Purpose and principles](#1-purpose-and-principles)
- [2. Scope of testing](#2-scope-of-testing)
- [3. Test cycles](#3-test-cycles)
- [4. Responsibilities](#4-responsibilities)
- [5. Entry and exit criteria per cycle](#5-entry-and-exit-criteria-per-cycle)
- [6. Environment per cycle](#6-environment-per-cycle)
- [7. Tools](#7-tools)
- [8. Metrics and reporting](#8-metrics-and-reporting)
- [9. Defect classification scheme](#9-defect-classification-scheme)
- [10. Daily triage procedure](#10-daily-triage-procedure)
- [11. Risks to the test effort](#11-risks-to-the-test-effort)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Customer | [Legal entity] |
| Document owner | [Name, customer test lead] |
| Status | [Draft / In review / Approved] |
| Version | [x.y] |
| Storage location | [Link to project repository] |
| Related documents | [Project management plan, data migration strategy, training strategy, cutover plan] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| [0.1] | [YYYY-MM-DD] | [name] | [First draft] |

 ## 1. Purpose and principles

 This strategy describes how [Customer] will prove that the IFS Cloud solution is fit for go-live. It covers what is tested, in which cycles, by whom, in which environment, and how results and defects are handled.

 Principles for this project:

 
1. Tests follow business processes end to end, not menus or modules.
2. Tests are executed with end-user logins and the permission sets those users will have in production. Nobody tests as an administrator.
3. Every test has a written expected result before it is run.
4. Every result is logged in the tracker on the day it is produced.
5. A defect has one owner and one target closure date at all times.
6. [Add project-specific principle]

 ## 2. Scope of testing

 
### 2.1 In scope

 | Area | What is tested | Source of truth |
| --- | --- | --- |
| Business processes | All processes in the confirmed solution scope | [Link to process model] |
| CRIM objects | Every configuration, report, integration and modification delivered by the project | [Link to CRIM log] |
| Security | Roles, permission sets, segregation of duties rules | [Link to role matrix] |
| Migrated data | Every data set in the data migration plan | [Link to data migration plan] |
| Devices and output | Printers, labels, mobile devices, scanners, document output | [List] |
| Example: Procure to pay | Example: Requisition to supplier payment, including supplier acknowledgement, receipt with inspection, three-way invoice matching | Example: Process model, area Procurement |

 
### 2.2 Out of scope

 | Item | Reason | Who accepted the exclusion |
| --- | --- | --- |
| [Item] | [Reason] | [Name, role] |
| Example: Standard functionality not used in any in-scope process | Example: Not part of the confirmed solution scope | Example: Customer PM |

 ## 3. Test cycles

 | # | Cycle | Purpose | Phase | Executed by | Supported by |
| --- | --- | --- | --- | --- | --- |
| 1 | Verify application solution | Build scenarios and run them in the test environment. Scripts track progress. Step-by-step guides capture the agreed procedure. | Establish Solution | Customer functional teams | Application consultants |
| 2 | Verify with security and migrated data | Rerun the processes with real permission sets and with data loaded through the migration routines. | Establish Solution | Customer functional teams, technical analysts | Application consultants, technical resources |
| 3 | Scenario scripting | Write the formal scripts: regular and exceptional activities, inputs, expected results, success criteria. | Establish Solution | Customer functional teams | Solution architect |
| 4 | Solution Acceptance Test (SAT) | Prove end-to-end flows in a copy of production with defined roles, migrated data, reports, devices and integrations. | Establish Solution | Customer functional teams | Supplier project team |
| 5 | Cutover test | Rehearse the cutover plan and checklist with full data volumes. Log durations. Correct the plan. | Implement Solution | Cutover manager, technical analysts | Supplier technical team |
| 6 | Expert user training | Train expert users first. This also tests the training material and the step-by-step guides. | Implement Solution | Customer trainers | Application consultants |
| 7 | Operational Readiness Test (ORT) | Expert users run the SAT scripts on their own. The core team advises only. Expert users confirm readiness on behalf of the business. | Implement Solution | Expert users | Core team (advice only) |
| 8 | Load test (optional) | Check concurrency, performance, reliability and volume. | Implement Solution | [Owner] | [Supplier technical team] |

 Load test decision: [Required / Not required]. Reason: [text]. Decided by: [name, role, date].

 ## 4. Responsibilities

 | Responsibility | Customer | Supplier |
| --- | --- | --- |
| Unit testing of CRIM objects before delivery | Informed | Responsible |
| Test strategy and test plan | Responsible | Consulted |
| Writing scenario scripts | Responsible | Consulted |
| Test data preparation | Responsible | Supports |
| Test execution in all cycles | Responsible | Supports |
| Tracker maintenance and reporting | Responsible | Informed |
| Defect triage | Responsible (chair) | Participates |
| Fixing application errors and CRIM defects | Informed | Responsible |
| Fixing data, training and procedure issues | Responsible | Supports |
| Cycle sign-off | Responsible | Consulted |

 Named roles:

 | Role | Name | Released time for testing |
| --- | --- | --- |
| Test lead | [name] | [agree in project] |
| Triage chair | [name] | [agree in project] |
| Script authors per process area | [names] | [agree in project] |
| Testers per process area | [names] | [agree in project] |
| Supplier test contact | [name] | [agree in project] |

 ## 5. Entry and exit criteria per cycle

 | Cycle | Entry criteria | Exit criteria | Who confirms exit |
| --- | --- | --- | --- |
| Verify application solution | [Prototype approved; test environment available; core team trained] | [All planned scenarios run; step-by-step guides drafted; CRIM needs specified] | [Customer PM] |
| Verify with security and migrated data | [Permission sets built; migration routines deliver a complete load] | [Processes run with end-user logins and migrated data; open defects classified] | [Customer PM] |
| Scenario scripting | [Process list frozen; script template agreed] | [Scripts reviewed by process owners; regular and exceptional cases covered] | [Test lead] |
| SAT | [Production copied to SAT environment; CRIM delivered; scripts approved; testers named] | [All scripts executed; no open defect that blocks deployment; completion report approved] | [Steering group] |
| Cutover test | [Cutover plan and checklist drafted; full-volume extract available] | [Rehearsal complete; durations logged; plan corrected; repeat rehearsal decided] | [Cutover manager] |
| Expert user training | [Material and guides final; training environment loaded] | [Expert users trained; feedback on material processed] | [Training lead] |
| ORT | [Expert users trained; ORT environment ready; users attached to roles] | [Expert users sign the confirmation statement] | [Steering group] |
| Load test | [Representative volumes loaded; test profile agreed] | [Results within the agreed limits: `[agree in project]`] | [Customer IT lead] |
| Example: SAT | Example: Use Place SAT environment refreshed from production baseline; open purchase orders and supplier master loaded through Data Migration Manager | Example: Every procure-to-pay script passed or has an accepted workaround recorded in the defect log | Example: Steering group |

 ## 6. Environment per cycle

 | Cycle | Environment | Data | Refresh rule | Owner |
| --- | --- | --- | --- | --- |
| [Cycle] | [Environment name] | [Sample / migrated / full volume] | [When and by whom] | [name] |
| Example: Verify application solution | Example: Use Place test environment | Example: Customer sample data | Example: No refresh during the cycle | Example: Customer IT lead |
| Example: SAT | Example: Use Place SAT environment, copied from the production baseline | Example: Latest migration load | Example: Refreshed once before the cycle, frozen until sign-off | Example: Customer IT lead |

 Rules:

 
- Modifications are built and unit tested in Build Place, then delivered to Use Place environments through the agreed delivery route: [describe].
- Configuration verified in test is moved to the production or reference environment as it is approved: [describe procedure and approver].
- Integrations point to [test endpoints] in every environment except production. Check this after each refresh.

 ## 7. Tools

 | Purpose | Tool | Administrator |
| --- | --- | --- |
| Test scripts | [Tool or folder] | [name] |
| Execution tracker | [Tool] | [name] |
| Defect log | [Tool] | [name] |
| Process model reference | [IFS Scope Tool project link] | [name] |
| Evidence storage (screenshots, exports) | [Location] | [name] |

 ## 8. Metrics and reporting

 | Metric | Definition | Reported to | Frequency |
| --- | --- | --- | --- |
| Script progress | Scripts planned, executed, passed, failed, blocked, per process area | [PMs, steering group] | [agree in project] |
| Defect status | Open and closed defects by cause, owner side and blocking flag | [PMs] | [agree in project] |
| Defect ageing | Open defects past their target closure date | [PMs] | [agree in project] |
| Retest backlog | Fixes delivered but not yet retested | [Test lead] | [agree in project] |
| [Metric] | [Definition] | [Audience] | [agree in project] |

 Report format: [link to report template]. Escalation rule: [when a metric triggers escalation to the steering group; agree in project].

 ## 9. Defect classification scheme

 Every logged item gets all of the following before it leaves triage.

 | Attribute | Values | Guidance |
| --- | --- | --- |
| Cause | Data / User error / Application error / Wrong solution | Data: migrated or basic data is wrong or missing. User error: the script, the guide or the training was not followed or is unclear. Application error: the software or a CRIM object does not behave as specified. Wrong solution: it works as designed, but the design does not meet the process need. |
| Blocks deployment | Yes / No | Yes if the business cannot operate the process in production and no acceptable workaround exists. |
| Contractual | Yes / No | Yes if the item concerns something the supplier committed to deliver. A No may become a change request. |
| Owner side | Customer / Supplier | One side only. |
| Owner | [Named person] | Never a team. |
| Target closure date | [YYYY-MM-DD] | Set in triage. Changed only in triage. |
| May close after the phase | Yes / No | Requires agreement of both PMs. Listed in the cycle sign-off. |

 | Example | Cause | Blocks | Contractual | Owner side |
| --- | --- | --- | --- | --- |
| Example: Supplier payment terms missing on migrated suppliers, invoice due dates wrong | Data | Yes | No | Customer |
| Example: Custom field on purchase order line not shown in the purchase order report | Application error | No | Yes | Supplier |

 "Wrong solution" items go through change control. They are not fixed as defects.

 ## 10. Daily triage procedure

 | Item | Agreement |
| --- | --- |
| Time and place | [agree in project] |
| Chair | [Test lead] |
| Attendees | [Process area leads, supplier test contact, technical analyst, data migration lead] |
| Input | All items logged since the last triage; all items past target date |
| Output | Classified items with owner and date; list of retests for the next day |

 Steps:

 
1. Review new items. Reject duplicates and items without a script reference and evidence.
2. Classify each item using section 9.
3. Assign owner side, named owner and target closure date.
4. Review blocking items first. Agree a workaround or replan the affected scripts.
5. Review items past their target date. Set a new date or escalate to the PMs.
6. Confirm the retest list and the testers.
7. Publish the updated log the same day to [distribution list].

 ## 11. Risks to the test effort

 | Risk | Mitigation | Owner |
| --- | --- | --- |
| Testers not released from daily work | [Backfill plan; test calendar agreed with line managers] | [Customer PM] |
| Migrated data arrives late or incomplete | [Align load cycles with test cycles; agree fallback data set] | [Data migration lead] |
| [Risk] | [Mitigation] | [name] |

 ## Approval

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer test lead (owner) | [name] | [Submitted] | [YYYY-MM-DD] |   |
| Customer project manager | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |
| Supplier project manager | [name] | [Reviewed] | [YYYY-MM-DD] |   |
| Steering group chair | [name] | [Approved / Rejected] | [YYYY-MM-DD] |   |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/17-test-strategy.md)

## Step-by-Step Guide (End-User Work Instruction) Template (IDK-16)

Template IDK-16, version 1.0. Phase: Establish Solution (drafted in solution workshops, final at SAT), revised in Implement Solution after ORT.

 ## How to use this template

 
- Write one guide per task that a user performs in one sitting. If the guide needs more than one role, split it.
- The guide is written by the customer's functional team, in the words end users use. That is deliberate: writing it proves the team understands the agreed solution, and the same document then serves as training material and as reference after go-live.
- Draft it during the solution workshops while running the scenario in the system. Correct it after SAT and again after ORT. Record both revisions in section 9.
- Describe what the user does and sees. Leave out configuration, basic data setup and the reasons behind design decisions. Those live in the Book of Rules.
- The example rows show the expected level of detail. Navigator paths and page names in examples must be confirmed in your own environment, because they differ between releases and configurations.
- Replace every `[...]` field. Delete the rows marked `Example:` before approval.

 | Field | Value |
| --- | --- |
| Template ID | IDK-16 |
| Phase | Establish Solution (drafted in solution workshops, final at SAT), revised in Implement Solution after ORT |
| Owner | Customer functional team member or expert user for the process |
| Approver | Customer process owner |
| Qualification gate | Solution Established |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Purpose](#1-purpose)
- [2. When to use this guide](#2-when-to-use-this-guide)
- [3. Role](#3-role)
- [4. Prerequisites](#4-prerequisites)
- [5. Terms used in this guide](#5-terms-used-in-this-guide)
- [6. Steps](#6-steps)
- [7. Exceptions and what to do](#7-exceptions-and-what-to-do)
- [8. Related guides](#8-related-guides)
- [9. Verification and revision record](#9-verification-and-revision-record)
- [10. Help and contacts](#10-help-and-contacts)
- [11. Approval](#11-approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Guide ID | [For example SBS-PUR-004] |
| Solution area and process | [Area, process, link to process model] |
| Process step covered | [Step] |
| Author | [Name, role] |
| Reviewed by (application consultant) | [Name] |
| Environment and release the screenshots come from | [Environment, release and service update level] |
| Language | [Language] |
| Status | [Draft / Verified in SAT / Verified in ORT / Released for training] |
| Storage location | [Link] |

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | Drafted in solution workshop |   |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change] | [Name] |

 ## 1. Purpose

 [One or two sentences in the user's language. What does the user achieve by following this guide, and why does it matter to the next person in the process?]

 Example: You record that goods from a supplier have arrived, so that the stock becomes visible to planners and the supplier invoice can be matched.

 ## 2. When to use this guide

 | Item | Description |
| --- | --- |
| Use it when | Example: A delivery arrives at the goods-in door with a delivery note that refers to a purchase order |
| Do not use it when | Example: The goods are a customer return, or the delivery has no purchase order reference. See section 7. |
| How often | [For example several times a day] |
| What happens before | [Previous step and who does it] |
| What happens after | [Next step and who does it] |

 ## 3. Role

 | Item | Description |
| --- | --- |
| Business role | Example: Goods receiver |
| Permission sets needed | [Names. If a page or command is missing on your screen, contact the person in section 10. Do not borrow a colleague's login.] |
| Sites | [Sites where this guide applies] |
| Device | [Desktop browser / Mobile device / Both. If both, state which one the screenshots show.] |

 ## 4. Prerequisites

 Check these before you start. If one is not true, stop and follow the note.

 | Prerequisite | If not fulfilled |
| --- | --- |
| Example: You have the supplier's delivery note with the purchase order number | Ask the driver or the buyer. Without an order reference, go to section 7, exception E3. |
| Example: The purchase order is released | Contact the buyer named on the order |
| [Prerequisite] | [Action] |

 ## 5. Terms used in this guide

 | Term on screen | What it means here |
| --- | --- |
| Example: Arrival | The goods are physically here and recorded, but may still need inspection or putaway |
| [Term] | [Meaning] |

 ## 6. Steps

 One action per row. Write the action as an instruction. Write the expected result as something the user can see on the screen.

 | Step | Page or navigator path | Action | Expected result | Screenshot |
| --- | --- | --- | --- | --- |
| Example: 1 | Procurement > Receipt > [Register arrivals page] (confirm the path in your environment) | Open the page. Search for the purchase order number from the delivery note. | The open lines of the order are listed with the quantity still due | `[Screenshot 1: search result]` |
| Example: 2 | Same page | Select the line that matches the part on the delivery note. Compare the part number and description with the label on the goods. | The line is highlighted. Part number matches the label. | `[Screenshot 2: line selected]` |
| Example: 3 | Same page, receive command | Enter the quantity you counted, not the quantity on the delivery note. Enter the arrival location [location]. Enter the lot number if the part requires one. Confirm. | The line shows the received quantity. The due quantity is reduced. A receipt reference appears. | `[Screenshot 3: receive dialog]` |
| Example: 4 | [Inventory part in stock page] | Search for the part and site | The quantity on hand at the arrival location has increased by what you received | `[Screenshot 4: stock record]` |
| [n] | [Page or path] | [Action] | [Expected result] | `[Screenshot n: caption]` |

 Rules for screenshots:

 
- Take them in the environment named in document control, logged in with the end-user role, not as an administrator.
- Use the agreed training data set. No real prices, supplier names or personal data from production.
- Mark the field or command the step refers to. One marking per screenshot.
- Retake screenshots when a page configuration changes or after a release update alters the page.

 ## 7. Exceptions and what to do

 List the exceptions that really happen. Normal exceptions first, then the rare ones. Each exception says what the user does, not only whom to call.

 | ID | Situation | What you do | Who to involve |
| --- | --- | --- | --- |
| Example: E1 | Quantity delivered is less than ordered | Receive the quantity you counted. The line stays open for the rest. Note the shortage on the delivery note. | Buyer is informed by [lobby / notification]. No call needed. |
| Example: E2 | Quantity delivered is more than ordered | Receive up to the ordered quantity. Place the surplus in [location] with a label. Do not receive it. | Buyer decides whether to keep or return it |
| Example: E3 | No purchase order can be found | Do not receive. Place goods in [location]. Record supplier, delivery note number and part on [form or page]. | Buyer for the supplier, or [contact] |
| Example: E4 | Goods are damaged | [Agreed handling, for example receive into the quarantine location and photograph the damage] | Buyer and quality role |
| Example: E5 | You received the wrong quantity or line by mistake | [Agreed correction procedure, or "stop and contact the expert user"] | Expert user |
| [ID] | [Situation] | [Action] | [Role] |

 Error messages you may see:

 | Message (as shown) | Usual cause | What to do |
| --- | --- | --- |
| [Message text] | [Cause] | [Action] |

 ## 8. Related guides

 | Guide ID | Title | Relation |
| --- | --- | --- |
| Example: SBS-PUR-003 | Follow up supplier confirmations | Comes before this guide, done by the buyer |
| Example: SBS-INV-002 | Move received goods to a storage location | Comes after this guide |
| [ID] | [Title] | [Before / After / Alternative / Exception handling] |

 Book of Rules reference for the decisions behind this procedure: [document, decision IDs]. Users do not need it to do the task.

 ## 9. Verification and revision record

 A guide is only trusted after people other than the author have followed it without help. Record each verification.

 
### 9.1 Revision after the Solution Acceptance Test (SAT)

 | Item | Record |
| --- | --- |
| SAT script and scenario where this guide was used | [Script ID, scenario] |
| Followed by (not the author) | [Name, role] |
| Could the tester complete the task using only this guide? | [Yes / No] |
| Steps that were wrong, missing or unclear | [Step numbers and findings] |
| Exceptions met in SAT that the guide did not cover | [Findings] |
| Corrections made | [Text, new version number] |
| Confirmed accurate by, date | [Name], [YYYY-MM-DD] |

 
### 9.2 Revision after the Operational Readiness Test (ORT)

 Expert users run ORT with the core team only advising. Their findings show what an end user will struggle with.

 | Item | Record |
| --- | --- |
| ORT script and scenario where this guide was used | [Script ID, scenario] |
| Followed by (expert user) | [Name, site] |
| Could the expert user complete the task without asking the core team? | [Yes / No] |
| Wording that users did not understand | [Findings] |
| Differences found between sites or devices | [Findings] |
| Corrections made | [Text, new version number] |
| Confirmed fit for end-user training by, date | [Name], [YYYY-MM-DD] |

 
### 9.3 Revision after go-live and at updates

 | Trigger | Check | Owner |
| --- | --- | --- |
| Repeated support questions on this task | Add or reword the step or exception | [Expert user] |
| Change to a page configuration, workflow or permission set that affects this task | Update steps and screenshots before the change reaches production | [Owner of the change] |
| Release update | Walk through the guide in the update test environment and retake screenshots where pages changed | [Expert user] |

 ## 10. Help and contacts

 | Need | Contact |
| --- | --- |
| First question about this task | Your expert user: [name or role per site] |
| Missing access | [Role or service desk route] |
| Suspected system fault | [Service desk route. Include guide ID, step number, the message shown and the order or part number.] |

 ## 11. Approval

 By approving, the process owner confirms that this guide describes the agreed way of working and may be used for end-user training.

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Author | [Name] | Submitted | [YYYY-MM-DD] |   |
| Application consultant (reviewed against the solution) | [Name] | [Reviewed / Comments] |   |   |
| Customer process owner | [Name] | [Approved / Approved with comments / Rejected] |   |   |
| Training lead (released for training) | [Name] |   |   |   |

 Comments and conditions: [text]

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/16-step-by-step-guide.md)

## Data Migration Plan and Customer Data Readiness Checklist (IDK-15)

Template IDK-15, version 1.0. Phase: Confirm Prototype (plan established), maintained through Establish Solution and Implement Solution.

 ## How to use this template

 
- This plan puts the data migration strategy (template [IDK-14](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/14-data-migration-strategy)) into practice. It lists every data object with its source, owner, method, load order and sign-off.
- Part A is the customer data readiness checklist. It needs no IFS Cloud environment. Start it on the day the project is approved.
- Part B is the plan per data object. It is split into three tables that share the same ID. In a spreadsheet they can be one wide table.
- Update the plan after every load cycle. The version at the end of the rehearsal feeds the hour-by-hour cutover checklist.
- Replace every `[...]` field. Delete the rows marked `Example:` once your own rows exist.

 | Field | Value |
| --- | --- |
| Template ID | IDK-15 |
| Phase | Confirm Prototype (plan established), maintained through Establish Solution and Implement Solution |
| Owner | Customer data migration lead, supported by the data migration consultant |
| Approver | Customer project manager, with sign-off per data object by the business data owner |
| Qualification gate | Solution Confirmed |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [A1. Inventory of sources](#a1-inventory-of-sources)
- [A2. Numbering schemes](#a2-numbering-schemes)
- [A3. Duplicates and conflicts](#a3-duplicates-and-conflicts)
- [A4. Active-only and history decisions](#a4-active-only-and-history-decisions)
- [A5. Units of measure](#a5-units-of-measure)
- [A6. Reference values](#a6-reference-values)
- [A7. Structured fields](#a7-structured-fields)
- [A8. Mandatory classifications](#a8-mandatory-classifications)
- [A9. Readiness summary](#a9-readiness-summary)
- [B1. Plan part 1: object, source and method](#b1-plan-part-1-object-source-and-method)
- [B2. Plan part 2: dependencies, load order and mapping](#b2-plan-part-2-dependencies-load-order-and-mapping)
- [B3. Cleansing tasks](#b3-cleansing-tasks)
- [B4. Plan part 3: load cycles, validation and sign-off](#b4-plan-part-3-load-cycles-validation-and-sign-off)
- [B5. Cycle calendar](#b5-cycle-calendar)
- [B6. Issues and decisions from load cycles](#b6-issues-and-decisions-from-load-cycles)
- [B7. Handling of extract files](#b7-handling-of-extract-files)
- [Approval](#approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Plan owner | [Name, role] |
| Data migration consultant (supplier) | [Name] |
| Strategy reference | [Link to the approved data migration strategy, version] |
| Status | [Draft / Established / Updated after cycle n / Final for cutover] |
| Storage location | [Link] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | Readiness checklist started |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change, for example "updated after load cycle n"] |

 Work through this per data group: parts, suppliers, customers, prices, structures, open transactions. Record findings, not just ticks. Every finding becomes a cleansing task in section B3.

 ## A1. Inventory of sources

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Every system, database, spreadsheet and paper file that holds data of this group is listed | Example: Supplier data sits in the legacy ERP, in a purchasing spreadsheet with contacts and in the accounts payable tool with bank details | [Name] | [ ] |
| For each source: who maintains it, how current it is, how it can be extracted | [Finding] | [Name] | [ ] |
| Where two sources hold the same record, the leading source is decided | [Finding] | [Name] | [ ] |
| Data held only in people's heads or mailboxes is identified | [Finding] | [Name] | [ ] |

 ## A2. Numbering schemes

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Current numbering logic is documented per object | Example: Part numbers carry the product family in the first characters. Newer parts no longer follow that rule. | [Name] | [ ] |
| Decision made: keep numbers or renumber | [Decision and reasoning] | [Name] | [ ] |
| If renumbering: cross-reference list is kept, and where users will find the old number | [Finding] | [Name] | [ ] |
| Numbers with meaning built in are reviewed. Classification fields do that job better. | [Finding] | [Name] | [ ] |
| Characters, length and leading zeros are checked against what the target fields accept | [Finding] | [Name] | [ ] |

 ## A3. Duplicates and conflicts

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Duplicate records are identified, within one source and across sources | Example: Same supplier created once per site, with different payment terms | [Name] | [ ] |
| Surviving record is chosen per duplicate set, and conflicting values are resolved by the owner | [Finding] | [Name] | [ ] |
| Open transactions on records that will be merged are listed | [Finding] | [Name] | [ ] |

 ## A4. Active-only and history decisions

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Rule for "active" is defined per object, in line with the strategy | Example: Parts with stock, open orders or movement since `[agree in project]` | [Name] | [ ] |
| Records outside the rule that the owner still wants are nominated by name, with a reason | [Finding] | [Name] | [ ] |
| Records to be left behind are marked in the source so extracts can exclude them | [Finding] | [Name] | [ ] |
| Unused fields are identified and dropped from the extract | [Finding] | [Name] | [ ] |

 ## A5. Units of measure

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| All units in use are listed, with spelling variants of the same unit | Example: "PCS", "pc", "each" and "EA" all mean one piece | [Name] | [ ] |
| One target unit list is agreed | [Finding] | [Name] | [ ] |
| Parts bought, stocked and sold in different units have verified conversion factors | [Finding] | [Name] | [ ] |
| Parts whose stocking unit should change are decided before balances are extracted | [Finding] | [Name] | [ ] |

 ## A6. Reference values

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Countries, currencies and languages use standard codes | Example: Country entered as free text in several spellings | [Name] | [ ] |
| Payment terms, delivery terms and ship-via values are rationalised to the list agreed in the Book of Rules | [Finding] | [Name] | [ ] |
| Groups and categories that nobody reports on are retired | [Finding] | [Name] | [ ] |
| A translation table from legacy value to target value exists per reference field | [Finding] | [Name] | [ ] |

 ## A7. Structured fields

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Addresses are split into the correct fields. Postcodes follow the country format. | [Finding] | [Name] | [ ] |
| Tax numbers, bank details, phone numbers and e-mail addresses are in valid formats | [Finding] | [Name] | [ ] |
| Information held in free-text notes that the new process needs as a field is identified and moved | Example: "Certificate required" written in the part note | [Name] | [ ] |
| Free-text notes that will not be migrated are agreed with the owner | [Finding] | [Name] | [ ] |

 ## A8. Mandatory classifications

 | Check | Finding | Owner | Done |
| --- | --- | --- | --- |
| Classifications the new processes depend on are listed from the Book of Rules | Example: Every purchased part needs a purchase part group, a planner and a primary supplier | [Name] | [ ] |
| Completeness is measured per classification in the legacy data | [Finding] | [Name] | [ ] |
| Missing values are assigned to owners to complete, at source where possible | [Finding] | [Name] | [ ] |
| Default values are avoided. A default hides a decision nobody made. | [Finding] | [Name] | [ ] |

 ## A9. Readiness summary

 | Data group | Owner | Sources known | Duplicates resolved | Active rule applied | Units and references clean | Classifications complete | Ready for first load |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: Suppliers | Purchasing manager | Yes | In progress | Yes | Yes | In progress | No |
| [Group] | [Name] | [Status] | [Status] | [Status] | [Status] | [Status] | [Yes / No] |

 ## B1. Plan part 1: object, source and method

 Method values: Migration job / Copy and paste or file import on a standard page / Manual entry / Configuration package.

 | ID | Data object | Scope rule | Source system and extract | Business owner | Technical owner | Method | Reason for method |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: DM-010 | Inventory parts | Active per rule in A4 | [Legacy ERP], extract [name] | Warehouse manager | [Name] | Migration job | Large set, loaded in every cycle |
| Example: DM-004 | Units of measure | Target list from A5 | Book of Rules | Warehouse manager | [Name] | Manual entry | Small set, entered once, then moved as configuration |
| Example: DM-030 | Open purchase order lines | Open quantity at cutover | [Legacy ERP], extract [name] | Purchasing manager | [Name] | Migration job | Volume, and must reconcile to legacy |
| [ID] | [Object] | [Rule] | [Source] | [Name] | [Name] | [Method] | [Reason] |

 ## B2. Plan part 2: dependencies, load order and mapping

 The load order follows the dependencies in the application: basic data before master data, master data before transactions.

 | ID | Load sequence | Depends on | Target (entity or page) | Mapping status | Mapping document | Open mapping questions |
| --- | --- | --- | --- | --- | --- | --- |
| Example: DM-010 | [n] | Units of measure, part groups, sites | Inventory part | Approved by owner [YYYY-MM-DD] | [Link] | None |
| Example: DM-030 | [n] | Suppliers, purchase parts, supplier for purchase part, sites | Purchase order and lines | Draft | [Link] | How are partly received lines loaded: open quantity only, or full line with receipt? |
| [ID] | [n] | [IDs or objects] | [Target] | [Not started / Draft / Approved] | [Link] | [Questions] |

 ## B3. Cleansing tasks

 | Task ID | Data object | Task | Where it is done | Owner | Due | Status | Measure of progress |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: CL-007 | Suppliers | Merge site-specific duplicates, agree one set of payment terms per supplier | Legacy ERP | Purchasing manager | [YYYY-MM-DD] | In progress | Duplicate sets remaining: [count] |
| [ID] | [Object] | [Task] | [Source system / Transformation step] | [Name] | [YYYY-MM-DD] | [Status] | [Measure] |

 ## B4. Plan part 3: load cycles, validation and sign-off

 Number of load cycles: `[agree in project]`. Add or remove cycle columns to match.

 | ID | Cycle 1 result | Cycle 2 result | Cycle [n] result | Rehearsal result and duration | Validation query or check | Reconciliation figure | Sign-off by owner, date |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: DM-010 | Sample loaded. Rejections: missing planner on [count] parts. | Full extract loaded. Rejections assigned as CL-012. |   | [Duration from log] | Count of parts per site and part status equals extract. Owner samples records field by field. A migrated part can be purchased and received. | Record count | [Name], [YYYY-MM-DD] |
| Example: DM-030 | Not in cycle | Full extract loaded |   | [Duration from log] | Open lines and open quantity per site and supplier equal the legacy open order report at the same cut-off | Line count, open quantity |   |
| [ID] | [Result] | [Result] | [Result] | [Result] | [Check] | [Figure] | [Name, date] |

 Per cycle, record for each object: records in extract, records loaded, records rejected, reasons, and the owner of each correction.

 ## B5. Cycle calendar

 | Cycle | Purpose | Environment | Extract date | Load window | Validation window | Objects included | Exit review |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: Cycle 1 | Prove jobs and load order with sample data | [Environment] | [YYYY-MM-DD] | [Dates] | [Dates] | Basic data, parts, suppliers | [Date, attendees] |
| [Cycle] | [Purpose] | [Environment] | [YYYY-MM-DD] | [Dates] | [Dates] | [Objects] | [YYYY-MM-DD] |
| Verification cycle before SAT | Processes run with real security and migrated data | [Environment] | [YYYY-MM-DD] | [Dates] | [Dates] | All | [YYYY-MM-DD] |
| Rehearsal | Full volumes, timings logged, plan corrected | [Environment] | [YYYY-MM-DD] | [Dates] | [Dates] | All | [YYYY-MM-DD] |
| Cutover | Production load | Production | [YYYY-MM-DD] | Per cutover checklist | Per cutover checklist | All | Release decision |

 ## B6. Issues and decisions from load cycles

 | ID | Cycle | Data object | Issue | Cause (data, mapping, job, solution) | Owner | Action | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| [ID] | [Cycle] | [Object] | [Issue] | [Cause] | [Name] | [Action] | [Open / Closed] |

 ## B7. Handling of extract files

 Follow the rules in the strategy. Record here where each cycle's files are stored and when they were deleted.

 | Cycle | Storage location | Access limited to | Deleted on, by |
| --- | --- | --- | --- |
| [Cycle] | [Location] | [Roles] | [Date, name] |

 ## Approval

 Approval at the Solution Confirmed gate states that the plan is established: source data is identified, cleansing is under way with named owners, and a method is chosen for every data object. Sign-off per object happens in table B4.

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer data migration lead | [Name] | [Approved / Approved with comments / Rejected] | [YYYY-MM-DD] |   |
| Customer project manager | [Name] |   |   |   |
| Data migration consultant (reviewed) | [Name] |   |   |   |
| Supplier project manager | [Name] |   |   |   |

 Final data sign-off at cutover:

 | Data group | Business owner | Reconciliation reference | Date | Signature |
| --- | --- | --- | --- | --- |
| [Group] | [Name] | [Link] | [YYYY-MM-DD] |   |

 Comments and conditions: [text]

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/15-data-migration-plan-and-readiness-checklist.md)

## Data Migration Strategy Template (IDK-14)

Template IDK-14, version 1.0. Phase: Initiate Project.

 ## How to use this template

 
- Write this document in the first phase. It sets the approach and the principles. The detail per data object belongs in the data migration plan (template [IDK-15](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/15-data-migration-plan-and-readiness-checklist)), which follows in Confirm Prototype.
- Its main job is to settle three arguments early: what is migrated, how much history comes along, and who owns the data. Get those decisions signed by the steering group.
- Where a value is needed, such as the number of load cycles, leave `[agree in project]` until the project has decided. Do not copy a figure from another project.
- The customer owns the data and this strategy. The supplier advises on method and tooling.
- Replace every `[...]` field. Delete the rows marked `Example:` before approval.

 | Field | Value |
| --- | --- |
| Template ID | IDK-14 |
| Phase | Initiate Project |
| Owner | Customer project manager, supported by the supplier project manager |
| Approver | Steering group |
| Qualification gate | Project Initiated |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Purpose and position in the project](#1-purpose-and-position-in-the-project)
- [2. Principles](#2-principles)
- [3. Scope by data object](#3-scope-by-data-object)
- [4. History depth decision](#4-history-depth-decision)
- [5. Ownership](#5-ownership)
- [6. Cleansing approach](#6-cleansing-approach)
- [7. Tooling and methods](#7-tooling-and-methods)
- [8. Load cycles, validation and reconciliation](#8-load-cycles-validation-and-reconciliation)
- [9. Security and privacy of extracts](#9-security-and-privacy-of-extracts)
- [10. Cutover implications](#10-cutover-implications)
- [11. Roles](#11-roles)
- [12. Risks](#12-risks)
- [13. Approval](#13-approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Document owner | [Name, role] |
| Data migration lead (customer) | [Name] |
| Data migration consultant (supplier) | [Name] |
| Status | [Draft / In review / Approved] |
| Storage location | [Link] |

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | First draft |   |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change] | [Name] |

 ## 1. Purpose and position in the project

 This strategy states how data will move from the legacy systems into IFS Cloud, on what principles, and who is responsible. It is one of the strategy documents confirmed at the Project Initiated gate.

 | Phase | Data migration activity | Document |
| --- | --- | --- |
| Initiate Project | Approach, principles, scope outline and responsibilities agreed | This strategy |
| Confirm Prototype | Every data object listed with source, owner and method. Cleansing under way. | Data migration plan (template [IDK-15](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/15-data-migration-plan-and-readiness-checklist)) |
| Establish Solution | Mapping, iterative loads, validation by functional teams, volume test | Plan updated per cycle, validation records |
| Implement Solution | Full rehearsal with complete volumes and logged timings | Cutover plan and cutover checklist |
| Go Live | Final extract, load, reconciliation and sign-off | Cutover checklist, reconciliation records |

 ## 2. Principles

 Adjust the wording. Keep the list short enough that people remember it.

 
1. The business owns the data. Each data object has a named business owner who decides what is migrated and signs off the result.
2. Migrate what the new processes need, not what the legacy system happens to hold.
3. Cleanse at the source, in the legacy system, wherever that is possible. Cleansing in spreadsheets between extract and load is repeated in every cycle and gets forgotten in one of them.
4. Cleansing starts now. It does not wait for the system to be installed.
5. Data is loaded through standard business logic, so invalid records are rejected at load. A rejection is a finding about the data, not a fault of the tool.
6. Every load is repeatable. Extract, transform and load steps are documented and rerun the same way in each cycle.
7. Every load is validated by the functional team that will use the data, against checks agreed beforehand.
8. Extracts contain real business data and are protected accordingly (section 9).
9. [Project-specific principle]

 ## 3. Scope by data object

 List data objects at group level here. The plan breaks them down further.

 | Data group | Examples of objects | In scope | Source systems | Business owner | Notes |
| --- | --- | --- | --- | --- | --- |
| Example: Supplier master | Suppliers, addresses, payment terms, supplier for purchase part | Yes, suppliers with activity inside the period decided in section 4 | [Legacy ERP], [spreadsheet held by purchasing] | Purchasing manager | Two sources overlap. Duplicates to be resolved before the first load. |
| Example: Inventory balances | Quantity on hand per part, location, lot | Yes, as of cutover | [Legacy ERP], confirmed by a count | Warehouse manager | Loaded at cutover only. Earlier cycles use a snapshot. |
| Basic data | [Units of measure, part groups, payment terms, delivery terms] | [Yes / No] | [Source, or "entered manually from the Book of Rules"] | [Role] | [Notes] |
| Master data | [Parts, customers, suppliers, price lists, structures] | [Yes / No] | [Source] | [Role] | [Notes] |
| Open transactions | [Open purchase orders, open customer orders, open balances] | [Yes / No] | [Source] | [Role] | [Notes] |
| Historical transactions | [Closed orders, transaction history] | [See section 4] | [Source] | [Role] | [Notes] |
| Documents and attachments | [Drawings, certificates] | [Yes / No] | [Source] | [Role] | [Notes] |

 Explicitly out of scope: [list, with the reason and where that data will remain available].

 ## 4. History depth decision

 How much history is migrated is a business decision with a real cost. Record it once, with reasons, and have the steering group confirm it.

 | Question | Decision | Reasoning | Decided by, date |
| --- | --- | --- | --- |
| Are closed transactions migrated at all? | [Yes / No / Only for listed objects] | [Reasoning] | [Name, date] |
| Which master data records count as active? | Example: Suppliers and parts with activity since `[agree in project]`, plus records named by the owner | Keeps the new system free of dead records. Owners can nominate exceptions. | [Name, date] |
| How will users reach older data after go-live? | [Legacy system kept read-only until `[agree in project]` / Archive database / Exported reports] | [Reasoning] | [Name, date] |
| Which legal retention duties apply, and how are they met? | [Text, confirmed by finance or legal] | [Reasoning] | [Name, date] |
| Are open transactions migrated or run down in the legacy system? | [Per object] | [Reasoning] | [Name, date] |
| Are statistics or planning history needed for forecasting? | [Yes / No, which] | [Reasoning] | [Name, date] |

 ## 5. Ownership

 | Responsibility | Customer | Supplier |
| --- | --- | --- |
| Decide scope and history depth | Accountable | Advises |
| Identify sources and extract data | Accountable and does the work | Advises on target format |
| Cleanse data | Accountable and does the work | Reports findings from loads |
| Map legacy fields to target fields | Functional teams decide the meaning | Provides target structure and migration job design |
| Build and run migration jobs | [Agree in project: customer technical analysts after training, or supplier] | [Agree in project] |
| Validate loaded data | Accountable, done by functional teams | Supports with checks and queries |
| Sign off each data object | Business owner | Not applicable |
| Protect extracts | Accountable | Follows the agreed handling rules |

 Named business owners per data group are listed in section 3. Owners need released time for this work. Cleansing fitted in around the day job is the most common reason migration runs late.

 ## 6. Cleansing approach

 | Item | Description |
| --- | --- |
| Start | Now. The readiness checklist in template [IDK-15](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/15-data-migration-plan-and-readiness-checklist) can be worked before the system is installed. |
| Where cleansing is done | [In the legacy system by default. Exceptions listed per object in the plan.] |
| Typical tasks | Remove duplicates, decide active records, complete mandatory classifications, rationalise units of measure, normalise reference values such as countries, fix structured fields such as postcodes, move content out of free-text notes |
| Renumbering | [Decision whether parts, customers or suppliers are renumbered, with the cross-reference kept where] |
| How findings from loads are fed back | [Rejected records listed per cycle, assigned to the business owner, corrected at source before the next cycle] |
| Progress reporting | [Measure per object, reported in the weekly project meeting] |

 ## 7. Tooling and methods

 | Method | When it is used | Notes |
| --- | --- | --- |
| Migration jobs in IFS Cloud (Data Migration Manager where licensed and agreed) | Medium and large data sets, anything loaded in more than one cycle | Loads through standard business logic. Jobs are reusable across cycles and at cutover. |
| Copy and paste or file import on standard pages | Small sets of basic data | Quick, but must be documented so it can be repeated |
| Manual entry | Very small sets, or data that needs a human decision per record | Doubles as training for key users. Record who enters what. |
| Configuration packages between environments | Basic data and configuration already verified in one environment | Not a migration from legacy, but part of the load sequence |

 | Item | Decision |
| --- | --- |
| Extract tooling on the legacy side | [Tool, owner] |
| Transformation tooling | [Tool, owner. State whether transformation rules are stored as scripts or done by hand.] |
| Target environments per cycle | [Environment names] |
| Technical training needed for the customer team | [Course, attendees, timing] |
| Where mapping documents and job definitions are stored | [Link] |

 ## 8. Load cycles, validation and reconciliation

 
### 8.1 Load cycles

 | Item | Value |
| --- | --- |
| Number of load cycles before the rehearsal | `[agree in project]` |
| Purpose of each cycle | Example: First cycle proves the jobs and the load order with a sample. Later cycles use full extracts. The last cycle before SAT runs with real security and feeds the SAT environment. |
| Entry criteria for a cycle | [Mapping approved for the objects in the cycle, extract delivered, environment ready] |
| Exit criteria for a cycle | [Rejections listed and assigned, validation checks run, results recorded] |
| Volume test | [Which cycle loads full volumes to prove run times] |
| Full rehearsal | In Implement Solution, with complete volumes, timings logged per step. More than one rehearsal is recommended. |

 
### 8.2 Validation and reconciliation approach

 | Level | What is checked | Who | Evidence |
| --- | --- | --- | --- |
| Technical | Records extracted, records loaded, records rejected, with reasons | Migration team | Load log per job |
| Reconciliation | Example: Count of open purchase order lines and total open quantity per site in legacy equals the same in IFS Cloud | Business owner with migration team | Reconciliation sheet, signed |
| Financial | [Inventory value, open balances agree with the legacy ledger at the cutover date] | Finance | Reconciliation sheet, signed |
| Functional | Processes run with migrated data: a migrated part can be ordered, received and issued | Functional team | Test script result |
| Sample | Records picked by the owner compared field by field | Business owner | Sample log |

 Tolerances for reconciliation differences: `[agree in project]`, decided by [role].

 ## 9. Security and privacy of extracts

 Extract files hold prices, supplier and customer details and sometimes personal data. They travel outside the access control of both systems.

 | Topic | Rule |
| --- | --- |
| Storage location for extracts and load files | [Named location with access restricted to the migration team] |
| Transfer between customer and supplier | [Agreed secure channel. Not e-mail attachments.] |
| Personal data | [Which objects contain it, legal basis, approval by the privacy owner] |
| Use of production data in test environments | [Allowed / Masked / Restricted to named environments] |
| Who may access which environment holding migrated data | [Roles] |
| Retention and deletion of extract files | [Deleted `[agree in project]` after go-live sign-off, by whom, with confirmation] |
| Copies on personal devices | Not allowed |

 ## 10. Cutover implications

 | Topic | Decision or approach |
| --- | --- |
| Timing | [Go-live date aligned with a financial period boundary, away from business peaks and holidays] |
| Legacy freeze | [When transactions stop in legacy, per area] |
| Static data loaded early | [Which objects are loaded before the cutover window, and how changes are kept in step until go-live] |
| Dynamic data loaded in the window | [Balances, open orders] |
| Duration of the migration steps | Taken from the rehearsal logs, not estimated |
| Point of no return | [Defined in the contingency plan, with the decision maker] |
| Backup | Production is backed up before release to users |
| Catch-up of transactions during the window | [How business done on paper during the freeze is entered] |
| Sign-off before release to users | [Business owners sign reconciliation, steering group or delegated authority releases] |

 ## 11. Roles

 | Role | Name | Responsibility |
| --- | --- | --- |
| Data migration lead (customer) | [Name] | Owns the plan, coordinates owners, reports progress |
| Business data owners | [Names per data group] | Scope, cleansing, validation, sign-off |
| Technical analysts (customer) | [Names] | Extracts, transformation, running migration jobs after training |
| Data migration consultant (supplier) | [Name] | Method, job design, support during loads |
| Application consultants (supplier) | [Names] | Target data structure, support for mapping decisions |
| Project managers | [Names] | Plan, resources, escalation |
| Privacy or security owner | [Name] | Approves handling rules in section 9 |

 ## 12. Risks

 | Risk | Mitigation | Owner |
| --- | --- | --- |
| Sources and data quality understood too late | Inventory of sources and cleansing start in the first phase | [Name] |
| Owners not released for cleansing and validation | Time commitment agreed by the steering group, tracked in the project plan | [Name] |
| Too few full iterations | Number of cycles agreed and planned, rehearsal with full volumes | [Name] |
| Technical team not trained on the tooling | Technical training scheduled before the first cycle | [Name] |
| [Risk] | [Mitigation] | [Name] |

 ## 13. Approval

 By approving, the steering group confirms the scope outline, the history depth decision, the ownership model and the handling rules for extracts.

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer project manager | [Name] | [Approved / Approved with comments / Rejected] | [YYYY-MM-DD] |   |
| Supplier project manager | [Name] |   |   |   |
| Customer sponsor | [Name] |   |   |   |
| Steering group chair | [Name] |   |   |   |

 Comments and conditions: [text]

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/14-data-migration-strategy.md)

## Interface Register Template (IDK-13)

Template IDK-13, version 1.0. Phase: Confirm Prototype (must exist before build starts), maintained through Go Live and into support.

 ## How to use this template

 
- List every interface: the ones that exist around the legacy system today and the ones the new solution will need. Include file drops, spreadsheets uploaded by hand on a schedule, and reports that another system reads. If data crosses a system boundary, it is an interface.
- Start the inventory in Confirm Prototype. The register must be complete before build starts, because a forgotten interface is usually found during cutover.
- The register is split into three tables that share the same ID: identification and flow (section 4), mechanism and security (section 5), operation and status (section 6). In a spreadsheet they can be one wide table.
- Every new or changed interface also gets a row in the CRIM log (template [IDK-10](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/10-crim-log)) and a functional specification (template [IDK-11](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/11-functional-specification-integration-modification)).
- Review the register at each gate and at every release update. Hand it to support at go-live.
- Delete the rows marked `Example:` once your own rows exist.

 | Field | Value |
| --- | --- |
| Template ID | IDK-13 |
| Phase | Confirm Prototype (must exist before build starts), maintained through Go Live and into support |
| Owner | Customer technical analyst for integrations, supported by the technical solution manager |
| Approver | Customer project manager, steering group for new write interfaces and retained legacy interfaces |
| Qualification gate | Solution Confirmed |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Rules for this register](#1-rules-for-this-register)
- [2. Value lists](#2-value-lists)
- [3. Decisions on legacy interfaces](#3-decisions-on-legacy-interfaces)
- [4. Register part A: identification and flow](#4-register-part-a-identification-and-flow)
- [5. Register part B: mechanism and security](#5-register-part-b-mechanism-and-security)
- [6. Register part C: operation and status](#6-register-part-c-operation-and-status)
- [7. Checks per interface before SAT](#7-checks-per-interface-before-sat)
- [8. Cutover and decommissioning](#8-cutover-and-decommissioning)
- [9. Review at each release update](#9-review-at-each-release-update)
- [10. Handover to support](#10-handover-to-support)
- [11. Approval](#11-approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Register owner | [Name, role] |
| Technical solution manager | [Name] |
| Security owner on the customer side | [Name] |
| Storage location | [Link] |
| Review rhythm | [For example at each gate, and before each release update] |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | Inventory of legacy interfaces |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change] |

 ## 1. Rules for this register

 
1. Every interface has one named business owner and one named technical owner on the customer side.
2. Every interface runs under its own integration account with its own permission set. No shared accounts and no personal accounts.
3. Read-only is the default. Write access to IFS Cloud is granted only with steering group authorisation and a functional specification.
4. Retaining a legacy interface is a decision, not a default. It needs the same authorisation as a new one.
5. Credentials have a named custodian. The register records who holds them, never the secret itself.
6. Every interface states how failures are detected and who acts on them. "Someone will notice" is not monitoring.
7. Updates to IFS Cloud go through standard projections or IFS Connect and their business logic. No direct database access.

 ## 2. Value lists

 | Column | Allowed values |
| --- | --- |
| Origin | Legacy retained / Legacy replaced by standard / Legacy retired / New |
| Direction | Inbound to IFS Cloud / Outbound from IFS Cloud / Both |
| Mechanism | REST/OData projection / IFS Connect (message routing, transformers, connectors) / File transfer / Event action / Manual upload / Other |
| Access | Read-only / Write |
| Status | Identified / Decision pending / Approved / Specified / In build / In test / Accepted / Live / Retired |

 ## 3. Decisions on legacy interfaces

 Walk through the legacy landscape with IT and the functional teams. Ask for each system: what goes in, what comes out, who would call if it stopped.

 | Legacy interface | Purpose today | Decision | Reasoning | Decided by, date | Register ID if retained or replaced |
| --- | --- | --- | --- | --- | --- |
| Example: Nightly stock file to the web shop | Web shop shows availability | Replaced by a read-only projection call | File is a day old, customers order stock that is gone | [Steering group], [YYYY-MM-DD] | INT-002 |
| Example: Purchase price export to a spreadsheet tool | Monthly price analysis by purchasing | Retired | Covered by a standard overview page and a lobby | [Customer PM], [YYYY-MM-DD] | None |
| [Interface] | [Purpose] | [Decision] | [Reasoning] | [Name, date] | [ID] |

 ## 4. Register part A: identification and flow

 | ID | Name | Origin | Source system | Target system | Direction | Data objects | Business owner | Technical owner |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: INT-001 | Supply chain exception monitoring | New | IFS Cloud | External monitoring service running in the customer network | Outbound from IFS Cloud | Purchase order lines, supplier confirmations, receipts. Object keys, dates, quantities and statuses. No writes. | Purchasing manager | [IT integration lead] |
| Example: INT-002 | Availability to web shop | Legacy replaced | IFS Cloud | Web shop | Outbound from IFS Cloud | Inventory part availability per site | Sales manager | [IT integration lead] |
| [ID] | [Name] | [Origin] | [Source] | [Target] | [Direction] | [Objects] | [Name] | [Name] |

 ## 5. Register part B: mechanism and security

 | ID | Mechanism | Projections, messages or files used | Access | Integration account | Permission set | Authentication | Credentials custodian | Network path |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: INT-001 | REST/OData projection | [Purchase order and receipt projections, entity sets listed in the specification] | Read-only | [Dedicated account, for example `SVC_PO_MONITOR_RO`] | [Dedicated permission set granting read on the listed projections only, no actions, no write] | [OAuth client credentials through the IFS identity provider] | [IT security officer]. Secret stored in [vault]. Rotated every `[agree in project]`. | Inside the customer network to the IFS Cloud endpoint over HTTPS. No inbound connection from outside. |
| Example: INT-002 | REST/OData projection | [Inventory availability projection] | Read-only | [Dedicated account] | [Dedicated permission set] | [OAuth client credentials] | [Web shop platform owner] | [Path] |
| [ID] | [Mechanism] | [Objects] | [Read-only / Write] | [Account] | [Permission set] | [Method] | [Role, storage, rotation] | [Path] |

 ## 6. Register part C: operation and status

 | ID | Frequency or trigger | Volume | Error handling | Monitoring and who acts | CRIM log ID | Specification link | Status | Test evidence |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: INT-001 | Scheduled poll every `[agree in project]` | `[agree in project]` | Failed reads are retried and logged with object keys only. The service cannot change data, so no business recovery is needed in IFS Cloud. | Service health check reviewed by [IT integration lead]. Failed authentication raises an alert to the credentials custodian. | [ID] | [Link] | In test | Read access verified with the integration account. Write attempt verified as refused. [Tester], [YYYY-MM-DD] |
| Example: INT-002 | On request from the web shop | `[agree in project]` | Web shop shows "availability on request" when the call fails | Web shop platform monitoring, alert to [owner] | [ID] | [Link] | Specified |   |
| [ID] | [Frequency] | [Volume] | [Handling] | [Monitoring, role] | [ID] | [Link] | [Status] | [Evidence] |

 ## 7. Checks per interface before SAT

 | Check | Done |
| --- | --- |
| Row complete in parts A, B and C | [ ] |
| Functional specification approved, commercial approval in place where needed | [ ] |
| Integration account created with its own permission set. Tested that it cannot do more than listed. | [ ] |
| For read-only interfaces: a write attempt has been tested and was refused | [ ] |
| Error handling tested with at least one forced failure | [ ] |
| Monitoring in place and the named person has received a test alert | [ ] |
| Volume test done where section 6 shows significant volume | [ ] |
| Interface included in an end-to-end SAT script | [ ] |
| Entry added to the cutover plan: switch-on time, legacy switch-off time, verification step | [ ] |

 ## 8. Cutover and decommissioning

 | ID | Action at cutover | When (reference to cutover plan line) | Owner | Verification | Rollback action |
| --- | --- | --- | --- | --- | --- |
| Example: INT-002 | Stop the nightly legacy file. Enable the projection call in the web shop. | [Line reference] | [IT integration lead] | Web shop shows availability for a test part that matches IFS Cloud | Re-enable the legacy file job |
| [ID] | [Action] | [Reference] | [Name] | [Check] | [Action] |

 Legacy interface accounts and scheduled jobs to remove after go-live: [list with owner and date].

 ## 9. Review at each release update

 | Check | Owner | Done |
| --- | --- | --- |
| Release notes read against the projections and messages in part B | [Role] | [ ] |
| Each live interface smoke-tested in the update test environment with its real account | [Role] | [ ] |
| Permission sets still grant what is listed and nothing more | [Role] | [ ] |
| Credentials rotation is up to date | [Role] | [ ] |
| Interfaces with status "Live" but no traffic: owner asked whether they can be retired | [Role] | [ ] |
| Register version updated and shared with support | [Role] | [ ] |

 ## 10. Handover to support

 The list of third-party integrations is part of the handover document. For each live interface, support receives the register row, the latest functional specification, the test specification, the name of the credentials custodian and the monitoring contact.

 | Item | Done |
| --- | --- |
| Register reflects production, verified by the technical owner | [ ] |
| Specifications at the linked locations are the latest versions and in English | [ ] |
| Support has been walked through each interface in the handover meeting | [ ] |

 ## 11. Approval

 Approval at the Solution Confirmed gate states that the inventory of legacy and new interfaces is complete to the best knowledge of those signing, and that the decisions in section 3 are authorised.

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer IT or integration lead | [Name] | [Approved / Approved with comments / Rejected] | [YYYY-MM-DD] |   |
| Customer security owner | [Name] |   |   |   |
| Customer project manager | [Name] |   |   |   |
| Technical solution manager (reviewed) | [Name] |   |   |   |
| Steering group chair (write interfaces and retained legacy interfaces) | [Name] |   |   |   |

 Comments and conditions: [text]

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/13-interface-register.md)

## Configuration and Report Specification Template (IDK-12)

Template IDK-12, version 1.0. Phase: Establish Solution.

 ## How to use this template

 
- Use one specification per configuration or report in the CRIM log (template [IDK-10](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/10-crim-log)): custom fields, custom events, page configurations, lobbies, workflows, quick reports and operational reports. Integrations and modifications use template [IDK-11](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/11-functional-specification-integration-modification).
- Fill sections 1 to 3 for every object. In section 4, keep only the block that matches the object type and delete the others.
- Build starts only after the customer project manager has approved in section 9. Changes after approval go through change control.
- Keep it short. A good configuration specification fits on a few pages and can be read by the process owner.
- Replace every `[...]` field. Delete the rows marked `Example:` before approval.

 | Field | Value |
| --- | --- |
| Template ID | IDK-12 |
| Phase | Establish Solution |
| Owner | Application consultant or customer technical analyst |
| Approver | Customer project manager |
| Qualification gate | Solution Established |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Business need and standard alternative](#1-business-need-and-standard-alternative)
- [2. Object and context](#2-object-and-context)
- [3. Logic in plain language](#3-logic-in-plain-language)
- [4. Object detail](#4-object-detail)
- [5. Permission sets affected](#5-permission-sets-affected)
- [6. Test cases](#6-test-cases)
- [7. Update-safety note](#7-update-safety-note)
- [8. Deployment](#8-deployment)
- [9. Approval](#9-approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| CRIM log ID | [ID] |
| Object type | [Custom field / Custom event / Page configuration / Lobby / Workflow / Quick report / Operational report / Other] |
| Solution area and process | [Area, process, link to process model] |
| Author | [Name, role] |
| Builder | [Name, role] |
| Status | [Draft / In review / Approved / Built / Tested / Accepted] |
| Storage location | [Link] |

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | First draft |   |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change] | [Name] |

 ## 1. Business need and standard alternative

 | Item | Description |
| --- | --- |
| Business need | Example: Goods receivers must see at arrival whether a purchase order line needs a supplier certificate, so that goods without one go to the quarantine location |
| Requested by | [Name, business role] |
| Book of Rules reference | [Document, decision ID] |
| Standard alternative considered | Example: Note text on the purchase order line was shown. It is free text, cannot be searched or made mandatory, and is often left empty. |
| Why a configuration is justified | [Text] |
| Consequence if not delivered | [Text] |

 ## 2. Object and context

 | Item | Description |
| --- | --- |
| Object name | [Name following the project naming convention] |
| Naming convention reference | [Link. Agree a prefix so customer objects are easy to find at update time.] |
| Page, entity or report the object belongs to | Example: Purchase order line entity, shown on the purchase order page and on the arrival registration page |
| Configuration context (page configurations) | [Global, or the named context and the rule that maps users or sites to it] |
| Sites and companies in scope | [List] |
| Business roles that use it | [Roles] |
| Related CRIM objects | [IDs] |

 ## 3. Logic in plain language

 Describe what the object does so that the process owner can confirm it. One short paragraph or a numbered list.

 Example:

 
1. A buyer ticks "Certificate required" on the purchase order line when the part belongs to a regulated part group.
2. The goods receiver sees the field, read-only, when registering the arrival.
3. When the field is ticked and no certificate is attached, a notification goes to the quality role.

 [Your text]

 ## 4. Object detail

 Keep the block that applies. Delete the rest.

 
### 4.1 Custom field

 | Item | Value |
| --- | --- |
| Entity | [Entity name as shown in entity configuration] |
| Field name and label | Example: `CERT_REQUIRED`, label "Certificate required" |
| Data type and length | Example: Boolean |
| Persistent or read-only (calculated) | [Persistent / Read-only, with the expression for read-only fields] |
| Default value | [Value] |
| Mandatory | [Yes / No, and from which status] |
| Value list or reference | [Enumeration values or referenced entity] |
| Pages where the field is placed | [Page, group, position] |
| Needed in reports, lobbies, integrations or migration | [List, with CRIM IDs] |
| Translations needed | [Languages] |

 
### 4.2 Custom event and event action

 | Item | Value |
| --- | --- |
| Entity and table the event listens to | [Name] |
| Fires when | [New record / Modified record / Removed record, and on which attributes] |
| Condition | Example: Certificate required is true, and the line status changes to arrived |
| Action type | [E-mail / Streams message / Execute online SQL / REST call / Other] |
| Recipients or target | [Role-based address or distribution, not a named person] |
| Message content | [Subject and body, with the substitution fields used] |
| Expected frequency | `[agree in project]` |
| What happens if the action fails | [Text. An event action that raises an error can block the user's transaction. State the intended behaviour.] |

 
### 4.3 Page configuration

 | Item | Value |
| --- | --- |
| Page | [Page name and navigator entry] |
| Change | Example: Add custom field to the line group, hide two unused fields, make the confirmed date column visible by default |
| Configuration context | [Context] |
| Conditional formatting or mandatory rules | [Rule] |
| Before and after screenshots | [Link] |
| Interaction with user personalisation | [Note whether users' own saved layouts are affected] |

 
### 4.4 Lobby

 | Item | Value |
| --- | --- |
| Lobby page name | Example: Buyer start page |
| Audience | [Business roles] |
| Page parameters | [For example site, buyer, date range] |

 | Element | Type | Data source | Filter and grouping | Drill-down target | Refresh expectation |
| --- | --- | --- | --- | --- | --- |
| Example: Unconfirmed lines | Counter with list | Purchase order lines | Released lines without confirmation, by buyer, older than `[agree in project]` days | Purchase order lines page with the same filter | On page load |
| [Element] | [Type] | [Data source] | [Filter] | [Target] | [Expectation] |

 Performance note: [Expected row counts per data source, and any data source that needs an index or a narrower filter].

 
### 4.5 Workflow (Business Process Automation)

 | Item | Value |
| --- | --- |
| Workflow name | [Name] |
| Purpose | [Validation / Enrichment of data / User interaction / Background process] |
| Trigger | [Projection and action or entity operation that starts it, and timing relative to the standard logic] |
| Steps | [Numbered list or BPMN diagram link] |
| Data read and written | [Projections, entities, fields] |
| Messages shown to the user | [Text and language] |
| Behaviour on failure | [Whether the user's transaction is stopped, and the message shown] |
| Volume expectation | `[agree in project]` |

 
### 4.6 Quick report

 | Item | Value |
| --- | --- |
| Report name and category | [Name, category] |
| Type | [SQL statement / Query designed in the client] |
| Parameters | [Name, type, default, mandatory] |
| Columns | [Column, source, format] |
| Selection logic in plain language | Example: All open purchase order lines where the promised date is earlier than today, for the sites the user is allowed to see |
| Data sources | [Views or projections. State how site and company access is respected.] |
| Expected row count and run time | `[agree in project]` |
| Output use | [On screen / Export / Scheduled] |

 
### 4.7 Operational report

 | Item | Value |
| --- | --- |
| Standard report used as the base | Example: Purchase order print-out |
| Layout name | [Name] |
| Changes to layout | [Logo, address block, columns added or removed, terms text] |
| Additional fields needed | [Field, source. Note whether the report data must be extended, which raises the tailoring level.] |
| Languages | [List] |
| Paper format and output channel | [Format, print, e-mail, archive] |
| Legal or customer-mandated content | [Text and the person who confirmed it] |
| Layout mock-up | [Link] |

 ## 5. Permission sets affected

 | Permission set | Change | Reason | Security owner informed |
| --- | --- | --- | --- |
| Example: [Buyer role permission set] | Grant access to the lobby page and its data sources | Buyers open it as start page | [Name, date] |
| Example: [Goods receiver permission set] | Read access to the custom field, no edit | Field is maintained by buyers only | [Name, date] |
| [Permission set] | [Change] | [Reason] | [Name, date] |

 Test with an end-user login that holds only the listed permission sets. An object that works for an administrator proves nothing.

 ## 6. Test cases

 | Test ID | Class | Login role | Preconditions and data | Steps | Expected result | Result, tester, date |
| --- | --- | --- | --- | --- | --- | --- |
| Example: T1 | Common | Goods receiver | Purchase order line with "Certificate required" ticked | Open arrival registration for the line | Field is visible and read-only | [Pass / Fail], [Name], [YYYY-MM-DD] |
| Example: T2 | Normal exception | Buyer at another site | Same line | Open the purchase order | Order is not accessible, in line with site access |   |
| [ID] | [Common / Normal exception / Specific exception] | [Role] | [Data] | [Steps] | [Expected] |   |

 Included in SAT script: [ID].

 ## 7. Update-safety note

 | Item | Description |
| --- | --- |
| Tailoring level | Configuration, unless section 4.7 requires extended report data |
| Standard objects this configuration depends on | [Pages, entities, fields, views, report] |
| What must be re-verified at each release update | Example: Field still placed correctly on both pages, event still fires, test cases T1 and T2 |
| What may break and how it would be noticed | [Text] |
| Owner of re-verification after go-live | [Customer role] |
| Retirement condition | [When standard covers the need, this object is removed] |

 ## 8. Deployment

 | Item | Description |
| --- | --- |
| Built in environment | [Environment] |
| Moved by | [Configuration package, named and versioned / manual steps listed here] |
| Target environments and order | [Test, SAT, production or reference environment] |
| Post-deployment steps | [Publish, approve, synchronise, grant, refresh] |
| Cutover plan entry needed | [Yes / No] |
| Step-by-step guides to update | [Guide IDs] |

 ## 9. Approval

 Build may start once the customer project manager has approved. The process owner confirms that section 3 matches the agreed way of working.

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer process owner (logic confirmed) | [Name] | [Approved / Approved with comments / Rejected] | [YYYY-MM-DD] |   |
| Customer project manager | [Name] |   |   |   |
| Technical solution manager (reviewed) | [Name] |   |   |   |

 Acceptance after test:

 | Role | Name | Test evidence reference | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer process owner | [Name] | [Link] | [YYYY-MM-DD] |   |

 Comments and conditions: [text]

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/12-configuration-and-report-specification.md)

## Functional Specification for an Integration or Modification (IDK-11)

Template IDK-11, version 1.0. Phase: Establish Solution.

 ## How to use this template

 
- Use one specification per integration or modification in the CRIM log (template [IDK-10](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/10-crim-log)). Configurations and reports use template [IDK-12](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/12-configuration-and-report-specification) instead.
- Do not start this document until the CRIM log shows the decision "Approved for specification". Do not start development until sections 13 and 14 are signed.
- Write sections 1 to 4 in business language so the process owner can approve them. Sections 5 to 9 may be technical.
- Section 11 is not optional. An integration or modification without a stated update impact will surprise someone at the first release update.
- Keep this document current after go-live. Support receives the latest version at handover, together with the test scenarios in section 10.
- Replace every `[...]` field. Delete the rows marked `Example:` before approval.

 | Field | Value |
| --- | --- |
| Template ID | IDK-11 |
| Phase | Establish Solution |
| Owner | Application consultant, with the technical solution manager |
| Approver | Customer process owner and customer project manager, commercial approval by both project managers, steering group authorisation |
| Qualification gate | Solution Established |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Business need](#1-business-need)
- [2. Process context](#2-process-context)
- [3. Current standard behaviour](#3-current-standard-behaviour)
- [4. Required behaviour](#4-required-behaviour)
- [5. Functional design](#5-functional-design)
- [6. Data and projections used](#6-data-and-projections-used)
- [7. Security](#7-security)
- [8. Error handling](#8-error-handling)
- [9. Volumes and performance](#9-volumes-and-performance)
- [10. Test scenarios](#10-test-scenarios)
- [11. Update impact](#11-update-impact)
- [12. Deployment and handover](#12-deployment-and-handover)
- [13. Estimate and commercial approval](#13-estimate-and-commercial-approval)
- [14. Approval](#14-approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| CRIM log ID | [ID] |
| Type | [Integration / Modification] |
| Interface register ID (integrations) | [ID] |
| Solution area and process | [Area, process, link to process model] |
| Author | [Name, role] |
| Technical designer | [Name] |
| Status | [Draft / In review / Approved / Revised] |
| Storage location | [Link] |

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | First draft |   |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change] | [Name] |

 ## 1. Business need

 State the need, not the solution. Name who has the need and what happens to the business if it is not met.

 | Item | Description |
| --- | --- |
| Need | Example: Buyers must see supplier order confirmations in IFS Cloud without keying them in, so that late or changed dates are visible on the day the supplier reports them |
| Who has the need | Example: Buyers at all sites, purchasing manager |
| Consequence if not met | Example: Confirmed dates stay in e-mail, planning runs on wanted dates, late deliveries are found at the dock |
| Book of Rules reference | [Document, decision ID] |
| Benefit the sponsor expects | [Text, link to business case item if any] |

 ## 2. Process context

 | Item | Description |
| --- | --- |
| Process and step affected | [Process, step in the process model] |
| Roles affected | [Business roles] |
| Sites and companies in scope | [List] |
| Upstream dependency | [What must have happened before] |
| Downstream effect | [What uses the result] |
| Other CRIM objects related | [IDs] |

 ## 3. Current standard behaviour

 Describe what standard IFS Cloud does today for this step. Verify it in the project environment before writing. Do not describe it from memory or from a previous version.

 | Item | Description |
| --- | --- |
| Standard functionality reviewed | Example: Manual entry of confirmed date and quantity on the purchase order line. Standard inbound message handling for order confirmations through IFS Connect. |
| Environment and version where it was verified | [Environment name, release and service update level] |
| Shown to | [Names, date] |
| Why standard is not sufficient | Example: The supplier portal cannot produce the standard message format, and manual entry does not scale with the number of lines |
| Standard alternatives rejected, with reason | [Alternative, reason] |

 ## 4. Required behaviour

 Number each requirement. Each one must be testable and must map to at least one scenario in section 10.

 | Req ID | Requirement | Priority | Source |
| --- | --- | --- | --- |
| Example: R1 | When the supplier portal reports a confirmation, the matching purchase order line shows the confirmed delivery date and quantity | Must | Book of Rules PUR-D07 |
| Example: R2 | A confirmation that does not match an open line is not applied. It is listed for the buyer with the reason. | Must | Workshop [YYYY-MM-DD] |
| [ID] | [Requirement] | [Must / Should / Could] | [Source] |

 Out of scope for this specification: [list explicitly].

 ## 5. Functional design

 
### 5.1 Overview

 [Short narrative of the solution, with a flow diagram or link. State where each part runs: inside IFS Cloud, in middleware, in the other system.]

 
### 5.2 Design steps

 | Step | Actor or component | Action | Result |
| --- | --- | --- | --- |
| Example: 1 | Supplier portal | Publishes a confirmation with order number, line, release, date and quantity | Message available to the integration layer |
| Example: 2 | Integration layer | Looks up the purchase order line through the projection, checks status and open quantity | Line found, or error per section 8 |
| Example: 3 | Integration layer | Calls the standard action that confirms the line | Standard business logic validates and updates the line |
| [n] | [Actor] | [Action] | [Result] |

 
### 5.3 User-visible changes

 | Page or lobby | Change | Roles that see it |
| --- | --- | --- |
| [Page] | [Change, or "none"] | [Roles] |

 
### 5.4 Design principles applied

 
- Updates go through standard projections and their business logic. No direct database writes.
- Prefer configuration and published interfaces over changed application code. State the tailoring level from the CRIM log: [Interface extension / Modification].
- [Project-specific principle]

 ## 6. Data and projections used

 Confirm projection, entity set and action names in the API Explorer of the project environment. Names below are placeholders until verified.

 | Projection | Entity set or action | Operation | Fields read or written | Verified in environment, date |
| --- | --- | --- | --- | --- |
| Example: [Purchase order handling projection] | [Purchase order line entity set] | Read | Order number, line, release, status, wanted date, open quantity | [Environment], [YYYY-MM-DD] |
| Example: [Purchase order handling projection] | [Confirm line action] | Write | Confirmed date, confirmed quantity | [Environment], [YYYY-MM-DD] |
| [Projection] | [Entity set / action] | [Read / Write] | [Fields] | [Verified] |

 Field mapping:

 | Source field | Target field | Transformation or rule | Mandatory |
| --- | --- | --- | --- |
| [Field] | [Field] | [Rule] | [Yes / No] |

 Custom fields, custom entities or configuration needed by this design: [list with CRIM IDs, or "none"].

 ## 7. Security

 | Item | Description |
| --- | --- |
| Integration account | [Account name. One account per integration, never a named person.] |
| Authentication method | [For example OAuth client credentials through the IFS identity provider] |
| Permission set | [Name. Grants only the projections and actions in section 6.] |
| Read-only or write | [Read-only / Write. Write access needs the steering group authorisation recorded in section 13.] |
| Credentials custodian | [Role that stores and rotates the secret] |
| Rotation and revocation | [How the secret is rotated, how access is removed at decommissioning] |
| Personal or sensitive data carried | [None / description, with the privacy owner's approval reference] |
| Network path | [Source, target, ports, encryption in transit] |
| Logging | [What is logged, where, retention, confirmation that logs hold keys only and no business content if required] |

 ## 8. Error handling

 | Error ID | Situation | Detection | System response | Who is notified and how | Recovery |
| --- | --- | --- | --- | --- | --- |
| Example: E1 | Order line not found or already closed | Lookup returns no open line | Message parked with reason, nothing updated | Buyer, through [lobby element / e-mail event] | Buyer corrects reference in the portal, message is reprocessed |
| Example: E2 | IFS Cloud not reachable | Call fails or times out | Retry `[agree in project]` times, then park | Integration owner, through monitoring alert | Automatic reprocessing when the connection returns |
| [ID] | [Situation] | [Detection] | [Response] | [Notification] | [Recovery] |

 Rules: no message is lost silently, no message is applied twice, and every parked message has an owner.

 ## 9. Volumes and performance

 Fill in with figures from the business. Do not estimate them in the project team.

 | Measure | Value | Source of the figure |
| --- | --- | --- |
| Transactions per day, normal | `[agree in project]` | [Name, role] |
| Transactions per day, peak | `[agree in project]` | [Name, role] |
| Largest single message or file | `[agree in project]` | [Name, role] |
| Required processing time | `[agree in project]` | [Name, role] |
| Operating window | `[agree in project]` | [Name, role] |
| Growth expected | `[agree in project]` | [Name, role] |

 Volume test required before SAT: [Yes / No, reference to test plan].

 ## 10. Test scenarios

 Cover the common flow first, then normal exceptions, then specific exceptions. These scenarios become the test specification handed to support.

 | Test ID | Covers | Class | Preconditions and data | Steps | Expected result | Result, tester, date |
| --- | --- | --- | --- | --- | --- | --- |
| Example: T1 | R1 | Common | Released purchase order with one open line | Publish a confirmation for the full quantity with a date later than wanted | Line shows confirmed date and quantity. Order history shows the change. No error parked. | [Pass / Fail], [Name], [YYYY-MM-DD] |
| Example: T2 | R2, E1 | Normal exception | Purchase order line already closed | Publish a confirmation for that line | Nothing updated. Message parked with reason. Buyer sees it in [place]. |   |
| [ID] | [Req IDs] | [Common / Normal exception / Specific exception] | [Data] | [Steps] | [Expected] |   |

 Test environments: unit test in [environment], integration test in [environment], included in SAT script [ID]. Tests run with the real integration account and permission set, not with an administrator account.

 ## 11. Update impact

 | Item | Description |
| --- | --- |
| Tailoring level | [Interface extension / Modification, from the CRIM log] |
| Delivered objects touched | [Projections, entities, pages, code modules] |
| What must be re-verified at each release update | Example: Names and signatures of the entity sets and actions in section 6, behaviour of the confirm action, permission set grants, scenarios T1 and T2 |
| What must be checked at each service update | [Usually a smoke test of scenario T1, state it] |
| Rebuild or uplift needed at release update | [No for Interface extension / Yes for Modification, with estimated effort `[agree in project]`] |
| Owner of re-verification | [Customer role after go-live] |
| Exit condition | [Under what circumstances this object can be retired, for example when standard covers the need] |

 ## 12. Deployment and handover

 | Item | Description |
| --- | --- |
| Delivery route | [Build Place to Use Place environments for code, configuration packages for configuration, deployment of external components] |
| Cutover steps needed | [Entries to add to the cutover plan] |
| Monitoring after go-live | [What is monitored, by whom] |
| Support owner | [Role] |
| Handover content | This specification, the test scenarios in section 10, the interface register row, credentials custodian details |

 ## 13. Estimate and commercial approval

 Development does not start before this section is complete.

 | Item | Value |
| --- | --- |
| Estimate for specification, build, test, documentation | `[agree in project]` |
| Estimate for recurring update effort | `[agree in project]` |
| Assumptions and exclusions | [Text] |
| Change request reference | [ID] |
| Steering group authorisation | [Meeting date, minute reference] |

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Supplier project manager | [Name] | [Approved / Rejected] | [YYYY-MM-DD] |   |
| Customer project manager | [Name] |   |   |   |
| Customer sponsor (if required by the contract) | [Name] |   |   |   |

 ## 14. Approval

 By approving, the customer confirms that sections 1 to 4 describe the need and the required behaviour correctly, that the test scenarios in section 10 are the basis for acceptance, and that the update impact in section 11 is understood.

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer process owner | [Name] | [Approved / Approved with comments / Rejected] | [YYYY-MM-DD] |   |
| Customer project manager | [Name] |   |   |   |
| Technical solution manager (technical design reviewed) | [Name] |   |   |   |
| Solution architect (coherence reviewed) | [Name] |   |   |   |

 Comments and conditions: [text]

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/11-functional-specification-integration-modification.md)

## CRIM Log Template (IDK-10)

Template IDK-10, version 1.0. Phase: Confirm Prototype (needs identified), Establish Solution (specified, built, tested).

 ## How to use this template

 
- CRIM stands for Configurations, Reports, Integrations and Modifications. This log is the single register of everything in the solution that is not plain standard functionality.
- Open the log at the first workshop. During Confirm Prototype you only record needs. Specification and build start in Establish Solution, after the decision column is filled.
- Every row must answer the question in the column "Standard alternative considered". A row without that answer is not ready for a decision.
- The register is split into two tables that share the same ID: section 5 covers need and decision, section 6 covers delivery and handover. In a spreadsheet they can be one wide table.
- Review the log at every weekly PM-to-PM meeting and present the summary in section 8 to each steering group.
- Delete the rows marked `Example:` once your own rows exist.

 | Field | Value |
| --- | --- |
| Template ID | IDK-10 |
| Phase | Confirm Prototype (needs identified), Establish Solution (specified, built, tested) |
| Owner | Supplier project manager, with the technical solution manager |
| Approver | Customer project manager for configurations and reports, steering group for integrations and modifications |
| Qualification gate | Solution Confirmed (needs identified), Solution Established (objects delivered) |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Purpose and the "standard first" rule](#1-purpose-and-the-standard-first-rule)
- [2. Type definitions](#2-type-definitions)
- [3. Tailoring levels and update impact](#3-tailoring-levels-and-update-impact)
- [4. Status values](#4-status-values)
- [5. Register part A: need and decision](#5-register-part-a-need-and-decision)
- [6. Register part B: delivery and handover](#6-register-part-b-delivery-and-handover)
- [7. Decision authority and change control](#7-decision-authority-and-change-control)
- [8. Summary for the steering group](#8-summary-for-the-steering-group)
- [9. Update-impact review](#9-update-impact-review)
- [10. Handover checklist](#10-handover-checklist)
- [11. Approval](#11-approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Log owner | [Name, role] |
| Technical solution manager | [Name] |
| Customer project manager | [Name] |
| Storage location | [Link] |
| Review rhythm | Weekly PM-to-PM meeting, summary to every steering group |

 | Version | Date | Author | Change |
| --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | Log opened |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change] |

 ## 1. Purpose and the "standard first" rule

 The aim of the project is to meet each process need with standard IFS Cloud functionality, and to keep the count of modifications, integrations and configurations as low as the business can accept. Every CRIM object has a cost at build time and again at every update. The log makes that cost visible before anyone commits to it.

 The rule, applied to every row:

 
1. Describe the business need, not the wished-for solution.
2. Show the standard functionality to the requester in the system. Record what was shown.
3. Record why standard is not sufficient, in the requester's words and with the consequence for the business.
4. Only then propose a CRIM object, at the lowest tailoring level that meets the need.
5. If the justification is "this is how the legacy system works", the row is rejected or sent back.

 ## 2. Type definitions

 | Type | Covers | Specification needed | Approval before build |
| --- | --- | --- | --- |
| C: Configuration | Custom fields, custom events, page configurations, lobbies, workflows (Business Process Automation), custom pages and similar objects created in the web client | Configuration and report specification (template [IDK-12](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/12-configuration-and-report-specification)) | Customer project manager |
| R: Report | Quick reports, operational report layouts, analysis models and other outputs beyond standard | Configuration and report specification (template [IDK-12](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/12-configuration-and-report-specification)) | Customer project manager |
| I: Integration | Any data exchange with another system, in either direction, including file transfers. Also listed in the interface register (template [IDK-13](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/13-interface-register)) | Functional specification (template [IDK-11](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/11-functional-specification-integration-modification)) | Customer approval, commercial agreement, steering group authorisation |
| M: Modification | Any change to delivered application logic or pages that goes beyond configuration | Functional specification (template [IDK-11](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/11-functional-specification-integration-modification)) | Customer approval, commercial agreement, steering group authorisation |

 ## 3. Tailoring levels and update impact

 Use these levels in the "Tailoring level" column. Adjust the wording to the terms agreed with your implementation partner.

 On the three-level scale used on ifs-erp.com: Standard corresponds to Level 1 Core, Configuration to Level 2 Configured, Modification to Level 3 Customized. An interface extension installs nothing in the tenant, so the core stays at Level 1, but the consumer carries the re-verification duty shown below.

 | Level | Meaning | Typical update impact |
| --- | --- | --- |
| Standard | Solved with standard functionality and basic data. Logged only to record the decision. | None beyond normal regression testing |
| Configuration | Created in the web client, stored as configuration, moved between environments as configuration packages | Low. Re-verify after each release update, especially page configurations and objects that rely on specific fields. |
| Interface extension (published interfaces) | External logic or integration that uses projections (REST/OData) or IFS Connect without changing delivered code | Medium. Re-verify the projections and entities consumed at each release update. |
| Modification | Changed or added application code, built and delivered through the Build Place | High. Must be uplifted, rebuilt and retested for each release update. Limits how often the customer can update. |

 ## 4. Status values

 | Status | Meaning |
| --- | --- |
| Identified | Need logged during a workshop. No decision yet. |
| Standard adopted | Standard alternative accepted. Row closed at Standard. |
| Rejected | Need not accepted. Reason recorded. |
| Approved for specification | Decision made to proceed. Specification may start. |
| Specified | Specification approved by the right approver (see section 2). |
| In build | Build started. For I and M, commercial approval is in place. |
| In test | Delivered to the test environment. Test evidence being collected. |
| Accepted | Customer has accepted the object based on test evidence. |
| Handed over | Latest functional and test specification delivered to support. |

 ## 5. Register part A: need and decision

 | ID | Type | Solution area and process | Business need | Standard alternative considered (what was shown, why it is not sufficient) | Decision | Decided by, date | Tailoring level | Update-impact note |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: CRIM-001 | C | Procurement, purchase to receipt | Buyers need one view of order lines the supplier has not confirmed | Standard purchase order lines overview with a saved search was shown. It works, but buyers want counts and ageing on their start page. | Approved as a lobby | [Customer PM], [YYYY-MM-DD] | Configuration | Lobby data source reads purchase order line data. Re-verify elements after each release update. |
| Example: CRIM-002 | M | Procurement, requisition approval | Requester asked for a bespoke approval screen like the legacy one | Standard authorisation rules plus an approver lobby were shown. They cover the delegation of authority policy fully. | Rejected, standard adopted | [Steering group], [YYYY-MM-DD] | Standard | None |
| Example: CRIM-003 | I | Inventory, stock visibility | Web shop must show available quantity per part | Standard projection for inventory part availability was reviewed. No standard connector to the web shop exists. | Approved for specification, read-only | [Steering group], [YYYY-MM-DD] | Interface extension | Re-verify projection and entity set names at each release update. See interface register [ID]. |
| [ID] | [C/R/I/M] | [Area, process] | [Need] | [Alternative and justification] | [Decision] | [Name, date] | [Standard / Configuration / Interface extension / Modification] | [Note] |

 ## 6. Register part B: delivery and handover

 | ID | Specification link and version | Estimate and commercial approval (I and M) | Builder | Status | Test evidence (script, result, tester, date) | Accepted by, date | Handover status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: CRIM-001 | [Link], v1.0 | Not applicable | [Customer technical analyst] | Accepted | SAT script [ID], passed, [tester], [YYYY-MM-DD] | [Process owner], [YYYY-MM-DD] | Specification and test case delivered to support on [YYYY-MM-DD] |
| Example: CRIM-003 | [Link], v1.2 | Estimate `[agree in project]`, change request [ID] approved [YYYY-MM-DD] | [Developer] | In test | Integration test [ID], open defect [ID] |   | Not started |
| [ID] | [Link] | [Reference] | [Name] | [Status] | [Evidence] | [Name, date] | [Status] |

 ## 7. Decision authority and change control

 | Situation | Who prepares | Who reviews | Who decides |
| --- | --- | --- | --- |
| New configuration or report need | Functional team: need, alternatives with pros and cons, proposal | Solution architect, technical solution manager | Customer project manager |
| New integration or modification need | Functional team: need, alternatives with pros and cons, proposal | Solution architects, then both project managers for cost | Sponsor agrees to table it, steering group authorises or rejects |
| Change to an approved specification | Author of the specification | Both project managers | Same authority as the original approval, through a written change request |
| Need raised after Solution Confirmed | As above | As above | Always through change control against the scope baseline |

 Write the disagreement down. In many cases, setting out the alternatives on paper resolves the question before it reaches the steering group.

 ## 8. Summary for the steering group

 | Type | Identified | Standard adopted or rejected | Approved | Specified | In build or test | Accepted | Handed over |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Configurations | [count] | [count] | [count] | [count] | [count] | [count] | [count] |
| Reports | [count] | [count] | [count] | [count] | [count] | [count] | [count] |
| Integrations | [count] | [count] | [count] | [count] | [count] | [count] | [count] |
| Modifications | [count] | [count] | [count] | [count] | [count] | [count] | [count] |

 Trend since the last steering group: [text]. Rows that need a steering group decision today: [IDs, each with a one-page decision paper].

 ## 9. Update-impact review

 Run this review when planning every release update, and in lighter form for service updates. The more Interface extension and Modification rows the log holds, the longer this review takes and the less often the customer can update. Say that plainly when a new row is proposed.

 | Check | Owner | Done |
| --- | --- | --- |
| All rows at Configuration, Interface extension and Modification listed with their update-impact note | [Role] | [ ] |
| Release notes read against the objects, projections and pages each row depends on | [Role] | [ ] |
| Regression test cases from the test evidence column scheduled in the update test plan | [Role] | [ ] |
| Modification rows: uplift effort estimated and agreed before the update date is committed | [Role] | [ ] |
| Rows no longer needed because standard now covers the need: proposed for retirement | [Role] | [ ] |

 ## 10. Handover checklist

 Support cannot verify a fix without a test specification. Check every accepted row before handover.

 | Check | Done |
| --- | --- |
| Latest approved specification stored at the link in part B | [ ] |
| Test specification with expected results stored with it | [ ] |
| Documents are in English | [ ] |
| Integrations also appear in the interface register with credentials custodian named | [ ] |
| Owner after go-live named on the customer side | [ ] |
| Row status set to "Handed over" only after the handover meeting | [ ] |

 ## 11. Approval

 Approval of this log at a gate confirms that the list of CRIM objects is complete for the phase and that the decisions recorded are those of the named authority. It is not approval of individual specifications.

 | Gate | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- | --- |
| Solution Confirmed | Customer project manager | [Name] | [Approved / Approved with comments / Rejected] | [YYYY-MM-DD] |   |
| Solution Confirmed | Steering group chair | [Name] |   |   |   |
| Solution Established | Customer project manager | [Name] |   |   |   |
| Solution Established | Steering group chair | [Name] |   |   |   |

 Comments and conditions: [text]

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/10-crim-log.md)

## Book of Rules Template (IDK-09)

Template IDK-09, version 1.0. Phase: Confirm Prototype (revised during Establish Solution).

 ## How to use this template

 
- Create one Book of Rules per solution area. Do not merge areas into a single file; each area has its own owner and its own approval.
- Fill sections 1 to 5 once per area. Copy section 6 for every process in the area.
- Write every decision together with the reasoning behind it. A decision without a reason gets reopened later, usually at the worst moment.
- Anything the standard solution cannot cover goes to section 6.8 as a CRIM candidate and is copied to the CRIM log (template [IDK-10](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/10-crim-log)). It is logged here, not specified here.
- Use the question bank in section 7 to prepare workshops. Delete it from the approved version if you prefer a shorter document.
- Replace every `[...]` field. Delete the rows marked `Example:` before approval.

 | Field | Value |
| --- | --- |
| Template ID | IDK-09 |
| Phase | Confirm Prototype (revised during Establish Solution) |
| Owner | Customer functional team lead, supported by the application consultant |
| Approver | Customer process owner and customer project manager |
| Qualification gate | Solution Confirmed |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Company and legal structure](#1-company-and-legal-structure)
- [2. Sites](#2-sites)
- [3. Financial steering model](#3-financial-steering-model)
- [4. Operational steering model](#4-operational-steering-model)
- [5. Guiding principles](#5-guiding-principles)
- [6. Process: [Process name, for example Purchase to receipt]](#6-process-process-name-for-example-purchase-to-receipt)
- [7. Question bank for workshops](#7-question-bank-for-workshops)
- [8. Approval](#8-approval)

 ## Document control

 | Field | Value |
| --- | --- |
| Project | [Project name] |
| Solution area | [Solution area] |
| Document owner | [Name, role] |
| Customer process owner | [Name] |
| Application consultant | [Name] |
| Status | [Draft / In review / Approved / Revised after solution workshops] |
| Storage location | [Link] |

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [Name] | First draft after workshop [reference] |   |
| [x.y] | [YYYY-MM-DD] | [Name] | [Change] | [Name] |

 ## 1. Company and legal structure

 Describe the legal entities that will operate in IFS Cloud and how they relate to each other. Keep it factual. This section drives the company setup, intercompany flows and tax handling.

 | Company ID | Legal entity | Country | Accounting currency | Role in the group | Trades with other group companies | Notes |
| --- | --- | --- | --- | --- | --- | --- |
| Example: 10 | [Parent trading company] | [Country] | [Currency] | Buys, stocks and sells finished goods | Yes, sells to company 20 | Tax registration in one country only |
| [ID] | [Name] | [Country] | [Currency] | [Role] | [Yes / No, with whom] | [Notes] |

 Open points on legal structure: [list, or "none"].

 ## 2. Sites

 A site in IFS Cloud belongs to one company and carries its own inventory, planning and calendars. Decide sites on operational grounds, not on how the legacy system was organised.

 | Site | Company | Type | Location | Processes run at this site | Distribution or manufacturing calendar | Notes |
| --- | --- | --- | --- | --- | --- | --- |
| Example: S01 | 10 | Central warehouse | [City] | Purchasing, receipt, storage, picking, shipment | [Calendar ID] | Supplies other sites through internal replenishment |
| [Site] | [Company] | [Type] | [Location] | [Processes] | [Calendar] | [Notes] |

 Decision on site structure and its reasoning: [text].

 ## 3. Financial steering model

 State what management needs to see in financial reporting and which structure in IFS Cloud will carry it. Agree this with finance before discussing part groups or supplier groups, because posting control depends on it.

 | Steering need | Who uses it | Carried by (account, code part, structure) | Decision | Reasoning |
| --- | --- | --- | --- | --- |
| Example: Purchase spend per category | Purchasing manager, controller | Code part fed through posting control from the purchase part group | Purchase part groups follow the spend categories used in management reporting | One classification serves both buyers and finance, no parallel mapping to maintain |
| [Need] | [Role] | [Structure] | [Decision] | [Reasoning] |

 Inventory valuation method and cost handling: [decision and reasoning]. Period closing expectations that affect this area: [text].

 ## 4. Operational steering model

 Describe how the business steers supply, stock and service. This is the customer's operating model in its own words.

 | Topic | How the business operates today | How it will operate in IFS Cloud | Reasoning |
| --- | --- | --- | --- |
| Example: Purchasing organisation | Each site buys for itself | Central buyers place orders for all sites, sites call off and receive | Better supplier terms and one owner per supplier relationship |
| Example: Replenishment of stocked parts | Manual review of spreadsheets | Planning method per inventory part, proposals converted by buyers | Removes manual stock review, buyers act on exceptions |
| [Topic] | [Today] | [Future] | [Reasoning] |

 Performance measures the area will be steered by: [list with owner per measure].

 ## 5. Guiding principles

 The functional team applies these principles to every decision in section 6. Adjust the wording, keep the list short.

 
1. Standard functionality first. A process need is met with the standard solution wherever that is workable. Anything else becomes a CRIM candidate and needs its own approval.
2. One way of working across sites, unless a legal or physical reason requires a difference. The reason is written down.
3. Decisions are made by the empowered process owner in the workshop, not deferred to a later committee.
4. Data is entered once, at its source, by the role that owns it.
5. Every decision records why it was made and which alternatives were rejected.
6. [Project-specific principle]

 ## 6. Process: [Process name, for example Purchase to receipt]

 Copy this whole section for each process in the solution area. Reference the process model in the scope tool: [link or process ID].

 
### 6.1 Purpose

 [One or two sentences. What business result does this process deliver, and for whom?]

 
### 6.2 Trigger and end point

 | Item | Description |
| --- | --- |
| Trigger | Example: A purchase requisition is released, or planning creates a purchase proposal for a stocked part |
| End point | Example: Goods are received into an inventory location and the receipt is available for invoice matching |
| Preceding process | [Process] |
| Following process | [Process] |

 
### 6.3 Roles

 | Business role | Responsibility in this process | Approximate user group | Permission set candidate |
| --- | --- | --- | --- |
| Example: Buyer | Converts requisitions and proposals to purchase orders, follows up confirmations | [Group] | [Name, to be defined in the security design] |
| [Role] | [Responsibility] | [Group] | [Candidate] |

 
### 6.4 Rules and decisions

 | ID | Topic | Decision | Reasoning | Alternatives rejected | Decided by | Date |
| --- | --- | --- | --- | --- | --- | --- |
| Example: PUR-D01 | Requisition use | Non-inventory purchases always start with a purchase requisition. Inventory purchases start from planning proposals. | Approvers get one place to authorise spend. Replenishment stays free of manual approval steps. | Requisitions for everything: rejected, slows replenishment without adding control | [Process owner] | [YYYY-MM-DD] |
| Example: PUR-D02 | Order authorisation | Purchase orders above `[agree in project]` require authorisation by the purchasing manager, using standard authorisation rules | Matches the delegation of authority policy. No bespoke approval screen needed. | E-mail approval outside the system: rejected, no audit trail | [Process owner] | [YYYY-MM-DD] |
| [ID] | [Topic] | [Decision] | [Reasoning] | [Alternatives] | [Name] | [YYYY-MM-DD] |

 
### 6.5 Basic data decisions

 | Basic data object | Decision | Values or naming convention | Owner after go-live | Reasoning |
| --- | --- | --- | --- | --- |
| Example: Purchase part groups | Follow spend categories from section 3 | [List or link] | Purchasing manager | Shared with financial reporting |
| Example: Inventory locations | Warehouse, bay, row, tier, bin structure mirrors the physical labels | [Convention] | Warehouse manager | Operators read the same code on the rack and on the screen |
| [Object] | [Decision] | [Values] | [Role] | [Reasoning] |

 
### 6.6 Exceptions

 Separate normal exceptions, which happen regularly, from specific exceptions, which are rare but must work. Testing will escalate in the same order.

 | ID | Exception | Class | How it is handled | Role |
| --- | --- | --- | --- | --- |
| Example: PUR-E01 | Supplier delivers more than ordered | Normal | Receive within the over-delivery tolerance on the supplier agreement, otherwise receive the ordered quantity and return the rest | Goods receiver, buyer |
| [ID] | [Exception] | [Normal / Specific] | [Handling] | [Role] |

 
### 6.7 Open questions

 | ID | Question | Owner | Needed by | Status | Answer |
| --- | --- | --- | --- | --- | --- |
| [ID] | [Question] | [Name] | [Date or milestone] | [Open / Answered] | [Answer and link to the decision in 6.4] |

 
### 6.8 CRIM candidates

 Log the need only. Specification happens later and only after the decision in the CRIM log.

 | Candidate | Type (C, R, I, M) | Business need | Standard alternative discussed | CRIM log ID |
| --- | --- | --- | --- | --- |
| Example: Buyer overview of unconfirmed order lines | C (lobby) | Buyers need one view of lines the supplier has not confirmed | Standard purchase order line overview with a saved search: workable, lobby preferred for daily use | [ID] |
| [Candidate] | [Type] | [Need] | [Alternative] | [ID] |

 
### 6.9 Data to migrate

 | Data object | Needed for this process because | Open transactions or master data | Owner | In migration plan |
| --- | --- | --- | --- | --- |
| Example: Supplier for purchase part | Prices and lead times must exist before the first proposal is converted | Master data | Purchasing manager | [Yes / No, reference] |
| [Object] | [Reason] | [Type] | [Role] | [Reference] |

 
### 6.10 Reports and information needed

 | Information need | User | Frequency | Covered by standard page, lobby or report | Gap |
| --- | --- | --- | --- | --- |
| Example: Open purchase order lines by promised date | Buyer | Daily | Standard overview page with saved search | None |
| [Need] | [Role] | [Frequency] | [Source] | [Gap, copy to 6.8 if any] |

 ## 7. Question bank for workshops

 Use these questions to prepare the workshop. They are prompts, not a checklist to read aloud. Ask "why" after every answer and write the reason down.

 
### 7.1 Purchasing

 
1. Who is allowed to commit the company to spend, and where is that authority written down?
2. Which purchases need a requisition and an approval, and which should flow without one?
3. Is buying central, local, or mixed? Who owns each supplier relationship?
4. How do buyers learn today that something needs ordering? Which of those signals should the system produce?
5. How are prices agreed: per order, price lists, agreements with validity dates, quantity breaks?
6. Which currencies and delivery terms are in use, and who decides them per supplier?
7. How does a supplier confirm an order, and what happens when nobody checks that it did?
8. What do you do when the confirmed date differs from the wanted date?
9. How are late deliveries noticed today, and by whom?
10. Do you buy parts that never enter stock, services, or subcontracted operations? How do those differ?
11. How are goods inspected at arrival? Which parts or suppliers require inspection and who decides?
12. What tolerances apply to over-delivery, under-delivery and early delivery?
13. How are returns to supplier and supplier claims handled and credited?
14. How is the supplier invoice matched: against order, against receipt, or both? Who resolves differences?
15. Which supplier classifications does anyone actually report on?
16. Do sites buy from each other? Is that a purchase, a transfer, or both from a legal view?
17. What information about a supplier must be complete before the first order can be placed?
18. Which purchasing documents go to suppliers, in which languages, by which channel?

 
### 7.2 Inventory

 
1. Which parts are stocked, and who decides that a part becomes stocked?
2. How should each group of parts be replenished: order point, planned from demand, or bought to order?
3. Who owns planning parameters such as safety stock, lot size and lead time, and how often are they reviewed?
4. How is the warehouse physically organised, and do location labels match what users will see on screen?
5. Which locations are for picking, which for bulk storage, arrival, inspection or quarantine?
6. Are lots, batches or serial numbers tracked? From receipt, or only at issue?
7. Do parts have shelf life or expiry dates? What happens to stock that expires?
8. How is stock that is blocked, damaged or under inspection kept away from planning and picking?
9. Does the company hold stock owned by customers or suppliers, or its own stock at a third party?
10. How are goods moved between locations and between sites, and who confirms the move?
11. How is counting done: full count, cycle counting, or both? Who approves count differences?
12. Which units of measure are used for stocking, purchasing and selling, and are the conversions reliable?
13. How is inventory valued, and who in finance owns that decision?
14. Which part classifications drive behaviour, and which are only descriptive?
15. What is the process for creating a new part, and which fields must be complete before it can be bought or sold?
16. How are obsolete parts phased out, and what blocks new purchases of them?
17. Will warehouse staff use mobile devices? For which transactions?
18. Which stock figures does management look at, and how are they defined?

 ## 8. Approval

 By approving, the customer confirms that this document describes how the business will operate in the solution area, and that the decisions in section 6 may be used as the basis for the prototype and for the solution build. Later changes go through project change control.

 | Role | Name | Decision | Date | Signature |
| --- | --- | --- | --- | --- |
| Customer process owner | [Name] | [Approved / Approved with comments / Rejected] | [YYYY-MM-DD] |   |
| Customer project manager | [Name] |   |   |   |
| Application consultant (reviewed) | [Name] |   |   |   |
| Solution architect (coherence across areas) | [Name] |   |   |   |

 Comments and conditions: [text]

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/09-book-of-rules.md)

## Change Request and Change Control Procedure Template (IDK-07)

Template IDK-07, version 1.0. Phase: All phases.

 ## How to use this template

 
- Part A (the procedure) is agreed once, during Initiate Project, and referenced from the Project Management Plan ([IDK-01](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/01-project-management-plan) section 6.4). Remind the whole team of it at the kick-off and at the start of every phase.
- Part B (the form) is copied for each change. The person who wants the change fills in sections B1 to B3. The project managers complete B4 and B5. The deciding body completes B6.
- Part C (the log) is kept by the project managers for the life of the project.
- Replace every `[bracketed field]`. Delete content marked `Example:` once you have your own.
- A change request is done when it carries a decision, a date and a name, and when the affected baselines, the Book of Rules and the plan have been updated. Until then, no work on the change is performed.

 | Field | Value |
| --- | --- |
| Template ID | IDK-07 |
| Phase | All phases |
| Owner | Customer project manager and supplier project manager (joint) |
| Approver | Steering group |
| Qualification gate | Project Initiated (procedure approved); applied until Go Live Complete |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [A1. What counts as a change](#a1-what-counts-as-a-change)
- [A2. The five-step ladder](#a2-the-five-step-ladder)
- [A3. Decision authority](#a3-decision-authority)
- [A4. Rules](#a4-rules)
- [B1. Description](#b1-description)
- [B2. Reason](#b2-reason)
- [B3. Alternatives considered](#b3-alternatives-considered)
- [B4. Impact assessment](#b4-impact-assessment)
- [B5. Estimate and commercial terms](#b5-estimate-and-commercial-terms)
- [B6. Decision record](#b6-decision-record)
- [Approval](#approval)

 ## Document control

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [name, role] | Procedure drafted |   |
| 1.0 | [YYYY-MM-DD] | [name, role] | Procedure approved for gate Project Initiated | [steering group chair] |

 ## A1. What counts as a change

 A change is anything that alters an approved baseline: solution scope, project scope, schedule or cost. In practice:

 | Counts as a change | Does not count as a change |
| --- | --- |
| A new process, site, company, data set or interface | Choosing between standard configuration options inside an in-scope process |
| Any new or altered CRIM object: configuration, report, integration, modification | Correcting a defect against an approved specification |
| More migrated history, or more load cycles, than agreed | Re-sequencing tasks inside a phase with no milestone affected |
| A document the supplier was not contracted to write | Clarifying wording in a document without changing its meaning |
| Moving a gate or the go-live date |   |
| Removing something from scope |   |

 If the two project managers disagree on whether something is a change, it is treated as one and written down. The written form usually settles the question.

 Design principle applied to every request: can the need be met with standard functionality, or by changing how the business works? Only when that has been examined and recorded does a CRIM object become an option. Each tailored object adds work at every service update and release update.

 ## A2. The five-step ladder

 A request climbs only as far as it needs to. Each step either resolves it, rejects it, or passes it up with a written recommendation.

 | Step | Who | What they do | Output | Target turnaround |
| --- | --- | --- | --- | --- |
| 1 | Functional team | Describes the problem, lists the alternatives with advantages and disadvantages, proposes a solution | Form sections B1 to B3 | [agree in project] |
| 2 | Solution architect and technical solution manager | Review the alternatives for fit with the whole solution and for update impact; may propose a standard way and close the request | Architect's review in B4 | [agree in project] |
| 3 | Both project managers | Assess impact on scope, schedule, cost and quality; obtain estimate and commercial terms; approve within their authority or recommend upward | Completed B4 and B5 | [agree in project] |
| 4 | Executive sponsor | Agrees that the request is worth the steering group's time, or sends it back | Sponsor's agreement in B6 | [agree in project] |
| 5 | Steering group | Authorises or rejects | Decision record B6, minuted | Next meeting, or written procedure if urgent |

 ## A3. Decision authority

 | Type of change | Decided by |
| --- | --- |
| No effect on any baseline (clarification) | Both PMs, recorded in the log |
| Configuration or report within the CRIM allowance, no milestone moved | [Customer PM / both PMs, agree in project] |
| Any integration or modification | Steering group |
| Any change to go-live date, gate dates, budget, or solution scope | Steering group |
| Use of contingency | Executive sponsor |

 Thresholds for cost and schedule effect: [agree in project].

 ## A4. Rules

 
1. No work starts on a change before its decision is recorded. This includes "quick" configurations made during a workshop.
2. A scope change that needs extra supplier work is confirmed as a written change to the statement of work before the work continues.
3. For integrations and modifications, a functional specification approved by the customer and a commercial agreement both precede development. For configurations and reports, a specification approved by the customer PM precedes build.
4. The effort to assess a large request is itself agreed beforehand: [who pays for estimation, agree in project].
5. Rejected and withdrawn requests stay in the log with the reason. They will be asked again.
6. After approval, the PMs update the baselines, the plan, the Book of Rules and the process model, and tell the people affected.
7. Open change requests are a standing item in the weekly project team meeting and in the steering group pack.

 **CR ID:** CR-[nnn] **Title:** [short title] **Date raised:** [YYYY-MM-DD] **Phase:** [phase] **Raised by:** [name, role] **Functional team / workstream:** [team] **Process owner:** [name] **Priority:** [must have before go-live / wanted before go-live / can wait until after go-live]

 ## B1. Description

 | Item | Content |
| --- | --- |
| What is requested | Example: A custom field "internal hazard class" on the part record, shown on the receipt page and included in the putaway report |
| Process area and process | Example: Inventory; receipt and putaway |
| Sites, companies, users affected | [list] |
| Baseline item it changes | [scope statement section, CRIM ID, milestone, document list entry] |

 ## B2. Reason

 | Item | Content |
| --- | --- |
| Business problem, in business terms | Example: Warehouse staff must segregate certain chemicals at putaway; the classification used today exists only in the legacy system |
| What happens if the change is not made | [consequence, who is affected, how often] |
| Legal, safety or audit requirement | [yes/no, reference] |
| Link to a project benefit ([IDK-02](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/02-project-scope-statement)) | [benefit ID or none] |
| Why this was not in the original scope | [reason; useful for the lessons learned] |

 ## B3. Alternatives considered

 Always include a standard-functionality alternative and a change-the-process alternative.

 | # | Alternative | Advantages | Disadvantages | Type (standard / C / R / I / M / process change) |
| --- | --- | --- | --- | --- |
| Example: 1 | Use a standard classification available on the part record (to be confirmed by the application consultant), mapped from the legacy classes | No tailoring; carried through updates without extra work | Legacy classes do not map one to one; data cleansing needed | Standard |
| Example: 2 | Custom field on the part record, display only | Quick to build in the web client; familiar values for users | Not used by system logic; one more object to check at each update; duplicate of a standard concept | C |
| Example: 3 | Keep the classification on a printed list at the receipt dock | No system work | Manual, error prone, not auditable | Process change |
| [n] | [alternative] | [pros] | [cons] | [type] |

 **Proposed solution (functional team):** [alternative number and reasoning]

 ## B4. Impact assessment

 Completed by the project managers with the solution architect and technical solution manager. "None" is a valid answer; an empty cell is not.

 | Area | Impact | Assessed by |
| --- | --- | --- |
| Solution scope | [processes added, changed, removed] | Solution architect |
| Project scope | [work packages, documents, responsibilities affected] | Both PMs |
| Schedule | [tasks added, milestones or gates affected, new forecast dates] | Both PMs |
| Cost | [supplier services, customer time, licences, third parties; one-off and recurring] | Both PMs |
| Quality and risk | [new risks, effect on acceptance criteria, risk register reference] | Both PMs |
| CRIM | [new or changed objects by type; specification needed; effect on service updates and release updates; who maintains it after go-live] | Technical solution manager |
| Data | [new fields to migrate, cleansing, mapping, extra load cycle] | Data migration lead |
| Integrations | [interface register entries affected; third parties to involve] | Technical analyst, integrations |
| Security | [roles and permission sets to change; segregation of duties] | Technical analyst, security |
| Training | [courses, step-by-step guides and material to change; users to retrain] | Training lead |
| Testing | [scripts to add or change; cycles to repeat; regression scope] | Test lead |
| Cutover and support | [cutover tasks, handover documentation] | Both PMs |

 **Architect's review:** [fit with overall solution; standard alternative confirmed as examined: yes/no; comment]

 ## B5. Estimate and commercial terms

 | Item | Value |
| --- | --- |
| Supplier effort and price | [estimate, basis, validity] |
| Customer effort | [estimate, who] |
| Funding source | [CRIM allowance / contingency / additional budget] |
| Statement of work amendment needed | [yes/no, reference] |
| PM recommendation | [approve / reject / defer until after go-live], with reason |

 | PM | Name | Date | Signature |
| --- | --- | --- | --- |
| Customer project manager | [name] | [YYYY-MM-DD] | ______________________ |
| Supplier project manager | [name] | [YYYY-MM-DD] | ______________________ |

 ## B6. Decision record

 | Item | Content |
| --- | --- |
| Sponsor agrees to table at steering group | [yes/no], [name], [YYYY-MM-DD] |
| Decision | [approved / approved with conditions / rejected / deferred to after go-live / withdrawn] |
| Alternative approved | [number from B3] |
| Conditions | [conditions with owner and date] |
| Reason, in one or two sentences | [reason; written for someone reading the log a year from now] |
| Decided by | [body or role], [meeting no. or written procedure], [YYYY-MM-DD] |
| Communicated to | [who was told, by whom, when] |

 Follow-up after approval:

 | Update | Done | By | Date |
| --- | --- | --- | --- |
| Schedule, cost, scope baselines re-versioned | [yes/no] | [name] | [YYYY-MM-DD] |
| Master implementation plan and workshop plan | [yes/no] | [name] | [YYYY-MM-DD] |
| Book of Rules and process model | [yes/no] | [name] | [YYYY-MM-DD] |
| CRIM log and interface register | [yes/no] | [name] | [YYYY-MM-DD] |
| Test scripts, training material, step-by-step guides | [yes/no] | [name] | [YYYY-MM-DD] |
| Risk register | [yes/no] | [name] | [YYYY-MM-DD] |

 | CR ID | Title | Raised | Raised by | Type | Step reached (1 to 5) | Status | Decision date | Cost effect | Schedule effect | Baseline version after change | Owner of implementation |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: CR-012 | Internal hazard class at receipt | [YYYY-MM-DD] | Functional team lead, inventory | Standard (alternative 1 chosen) | 2 | Closed at architect review, no baseline change | [YYYY-MM-DD] | None | None | Unchanged | Data migration lead (mapping) |
| Example: CR-015 | Outbound order status messages to transport planning system | [YYYY-MM-DD] | Technical analyst, integrations | I | 5 | Approved with conditions | [YYYY-MM-DD] | [amount] | [effect] | [n.n] | Technical solution manager |
| [ID] | [title] | [YYYY-MM-DD] | [name] | [type] | [step] | [status] | [YYYY-MM-DD] | [effect] | [effect] | [version] | [name] |

 Summary for the steering group pack:

 | Status | Count | Cumulative cost effect | Cumulative schedule effect |
| --- | --- | --- | --- |
| Open | [n] |   |   |
| Approved | [n] | [amount] | [effect] |
| Rejected or withdrawn | [n] |   |   |
| Deferred to after go-live | [n] |   |   |

 ## Approval

 Procedure (Part A):

 | Name | Role | Date | Signature |
| --- | --- | --- | --- |
| [name] | Executive sponsor (customer) | [YYYY-MM-DD] | ______________________ |
| [name] | Sponsor (supplier) | [YYYY-MM-DD] | ______________________ |
| [name] | Customer project manager | [YYYY-MM-DD] | ______________________ |
| [name] | Supplier project manager | [YYYY-MM-DD] | ______________________ |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/07-change-request-and-change-control-procedure.md)

## Qualification Gate Checklists Template (IDK-08)

Template IDK-08, version 1.0. Phase: All phases.

 ## How to use this template

 
- Agree the five checklists during Initiate Project, so that everyone knows from the start what "phase finished" means. Adjust items to the contract; do not remove an item without writing down why.
- The two project managers keep the checklist of the current phase up to date through the phase, and report its status in the steering group pack ([IDK-06](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/06-steering-group-pack), section C7). A gate should never be a surprise.
- Evidence means a document, a signed record or a system state that a third person can inspect. "Discussed" and "in progress" are not evidence.
- Status values: Complete, In progress, At risk, Not started, Not applicable (with reason).
- A gate is done when the steering group has signed the gate decision record in section 6. If the decision is "approved with conditions", each condition has an owner and a date and is tracked to closure at the next meeting.
- Replace every `[bracketed field]`. Delete rows marked `Example:` once you have your own.

 | Field | Value |
| --- | --- |
| Template ID | IDK-08 |
| Phase | All phases |
| Owner | Customer project manager and supplier project manager (joint) |
| Approver | Steering group |
| Qualification gate | All five gates (Project Initiated, Solution Confirmed, Solution Established, Go Live Authorised, Go Live Complete) |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [Overview](#overview)
- [1. Gate: Project Initiated](#1-gate-project-initiated)
- [2. Gate: Solution Confirmed](#2-gate-solution-confirmed)
- [3. Gate: Solution Established](#3-gate-solution-established)
- [4. Gate: Go Live Authorised](#4-gate-go-live-authorised)
- [5. Gate: Go Live Complete](#5-gate-go-live-complete)
- [6. Gate decision record](#6-gate-decision-record)
- [Approval](#approval)

 ## Document control

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [name, role] | Checklists adapted to the project |   |
| 1.0 | [YYYY-MM-DD] | [name, role] | Checklists agreed at gate Project Initiated | [steering group chair] |
| [n.n] | [YYYY-MM-DD] | [name, role] | Gate [name] decision recorded | [steering group chair] |

 ## Overview

 | # | Phase | Gate | Planned date | Actual date | Decision |
| --- | --- | --- | --- | --- | --- |
| 1 | Initiate Project | Project Initiated | [YYYY-MM-DD] | [YYYY-MM-DD] | [decision] |
| 2 | Confirm Prototype | Solution Confirmed | [YYYY-MM-DD] | [YYYY-MM-DD] | [decision] |
| 3 | Establish Solution | Solution Established | [YYYY-MM-DD] | [YYYY-MM-DD] | [decision] |
| 4 | Implement Solution | Go Live Authorised | [YYYY-MM-DD] | [YYYY-MM-DD] | [decision] |
| 5 | Go Live | Go Live Complete | [YYYY-MM-DD] | [YYYY-MM-DD] | [decision] |

 How a filled-in row looks:

 | # | Item | Evidence required | Owner | Status | Comment |
| --- | --- | --- | --- | --- | --- |
| Example: 3.1 | Roles and permission sets created | Role catalogue approved by process owners; functional roles for buyer, warehouse operator and accounts payable clerk exist in the production environment; acceptance test executed with those roles | Technical analyst, security | In progress | Warehouse roles awaiting process owner review; forecast [YYYY-MM-DD] |

 ## 1. Gate: Project Initiated

 Question the steering group answers: are both organisations mobilised, and is there an agreed plan, scope and set of controls to start designing?

 | # | Item | Evidence required | Owner | Status | Comment |
| --- | --- | --- | --- | --- | --- |
| 1.1 | Purpose, objectives and scope confirmed in writing | Signed Project Scope Statement ([IDK-02](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/02-project-scope-statement)), with benefits, owners and acceptance criteria | Supplier PM | [status] | [comment] |
| 1.2 | Project organisation and governance confirmed | Approved Project Organisation and RACI ([IDK-03](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/03-project-organisation-and-raci)); steering group terms of reference approved ([IDK-06](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/06-steering-group-pack) Part A); all steering group dates booked | Both PMs | [status] | [comment] |
| 1.3 | Core team released | Time commitment and backfill table signed by line managers ([IDK-03](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/03-project-organisation-and-raci) section 6) | Executive sponsor | [status] | [comment] |
| 1.4 | Project plan with resources in place | Approved Project Management Plan ([IDK-01](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/01-project-management-plan)); master implementation plan and workshop and activity plan with named resources on both sides | Supplier PM | [status] | [comment] |
| 1.5 | Project controls defined | Risk register and issue log live ([IDK-04](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/04-risk-register-and-issue-log)); change control procedure approved ([IDK-07](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure)); status reporting procedure agreed; project tracker set up | Customer PM | [status] | [comment] |
| 1.6 | Process ownership verified | Named process owner per in-scope process area, confirmed by the sponsor | Executive sponsor | [status] | [comment] |
| 1.7 | Data migration scope and responsibilities agreed (template [IDK-14](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/14-data-migration-strategy)) | Data strategy (approach and principles); data scope table with customer owners ([IDK-02](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/02-project-scope-statement) section 4.1) | Customer data lead | [status] | [comment] |
| 1.8 | Training needs identified | Training needs list for core team, technical team and end-user groups; core team training booked | Customer PM | [status] | [comment] |
| 1.9 | Strategy documents approved or scheduled | Testing, training, communication, data, infrastructure, business change, legacy decommissioning: each approved, or has an owner and due date accepted by the steering group | Customer PM | [status] | [comment] |
| 1.10 | Communication plan in place | Approved Communication Plan and Stakeholder Analysis ([IDK-05](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/05-communication-plan-and-stakeholder-analysis)); first communication sent | Customer PM | [status] | [comment] |
| 1.11 | Environments for training and test available | Build Place set up; Use Place environments created for the agreed deployment option; team members can log in with named accounts | Supplier systems engineer, customer IT lead | [status] | [comment] |
| 1.12 | Document list agreed | List of documents the supplier will and will not write, with examples shown ([IDK-01](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/01-project-management-plan) section 10) | Both PMs | [status] | [comment] |
| 1.13 | Update approach discussed (template [IDK-23](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/23-update-strategy-evergreen)) | Agreed position on service updates and release updates during and after the project, recorded in [IDK-01](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/01-project-management-plan) section 9 | Technical solution manager | [status] | [comment] |
| 1.14 | Next phase scheduled and resourced | Confirm Prototype plan with kick-off date, workshop calendar and confirmed attendees | Both PMs | [status] | [comment] |

 ## 2. Gate: Solution Confirmed

 Question: has the prototype shown that the solution scope is right, and do we know what has to be built, migrated and integrated?

 | # | Item | Evidence required | Owner | Status | Comment |
| --- | --- | --- | --- | --- | --- |
| 2.1 | Kick-off held | Agenda, attendee list, material published; change control procedure presented | Both PMs | [status] | [comment] |
| 2.2 | Core team overview training completed | Attendance record per core team member; gaps have a catch-up date | Customer PM | [status] | [comment] |
| 2.3 | Book of Rules documents approved by the customer (template [IDK-09](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/09-book-of-rules)) | Approved documents covering the operating model (steering model, legal and operational structure, answers per solution area), signed by process owners | Process owners | [status] | [comment] |
| 2.4 | Process model current | In-scope processes maintained in [IFS Scope Tool or agreed repository], matching the scope statement | Solution architect | [status] | [comment] |
| 2.5 | CRIM requirements identified (template [IDK-10](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/10-crim-log)) | CRIM log with type, business reason and process owner per item. Items are logged, not yet specified. Standard alternative recorded for each. | Technical solution manager | [status] | [comment] |
| 2.6 | Interface register exists (template [IDK-13](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/13-interface-register)) | Every legacy and new interface listed with source, target and data flowing; retired interfaces marked | Technical analyst, integrations | [status] | [comment] |
| 2.7 | Data migration plan established (template [IDK-15](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/15-data-migration-plan-and-readiness-checklist)) | Plan listing every data set with method (migration tool, copy and paste, manual), owner, number of load cycles and depth of history agreed | Customer data lead | [status] | [comment] |
| 2.8 | Source data identified and cleansing under way | Source inventory per data set; cleansing task list with owners and first progress report | Data owners | [status] | [comment] |
| 2.9 | Production infrastructure defined, where relevant | Infrastructure definition for the deployment option, including devices, printers and network prerequisites at sites | Customer IT lead | [status] | [comment] |
| 2.10 | Prototype approved and solution scope confirmed | Prototype demonstrated end to end on customer sample data; approval signed by process owners; scope statement re-confirmed or changed through [IDK-07](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure) | Process owners, both PMs | [status] | [comment] |
| 2.11 | Customer tasks planned | Customer testing, data and documentation tasks in the plan with owners and dates; number of build cycles agreed | Customer PM | [status] | [comment] |
| 2.12 | Business change readiness checked | Named change lead; change plan with activities and owners; position on end-user training strategy, organisation design and update of policies and procedures | Change lead | [status] | [comment] |
| 2.13 | Next phase scheduled and resourced | Establish Solution plan: solution workshops, technical training, test cycles, load iterations, with confirmed resources | Both PMs | [status] | [comment] |

 ## 3. Gate: Solution Established

 Question: is the solution designed, built and tested, and has the business accepted it?

 | # | Item | Evidence required | Owner | Status | Comment |
| --- | --- | --- | --- | --- | --- |
| 3.1 | Roles and permission sets created | Role catalogue approved by process owners; roles exist in the production environment; segregation of duties reviewed by finance | Technical analyst, security | [status] | [comment] |
| 3.2 | Production functional and technical configuration complete | Verified configuration moved to the production (or reference) environment; static data loaded; security defined; environment declared the baseline | Application consultants, customer functional leads | [status] | [comment] |
| 3.3 | Core team and technical training completed | Attendance records for process training and technical training (administration, permission sets, data import tooling, technical configuration) | Customer PM | [status] | [comment] |
| 3.4 | Book of Rules revised | Updated documents reflecting decisions from the solution workshops, with the reasoning recorded | Functional team leads | [status] | [comment] |
| 3.5 | CRIM delivered | Each object: approved specification, delivered, unit tested by supplier, tested by customer; every object traceable to an approved change request or the baseline | Technical solution manager | [status] | [comment] |
| 3.6 | Migration routines validated with volume tests | Load iteration reports; functional validation sign-off per data set; load timings recorded for cutover planning | Customer data lead | [status] | [comment] |
| 3.7 | Verification with security and migrated data completed | Test cycle report: processes run with end-user roles and migrated data | Test lead | [status] | [comment] |
| 3.8 | Solution Acceptance Test completed, documented and approved (template [IDK-18](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/18-sat-ort-test-script-and-signoff)) | Test report: scripts executed end to end with defined roles, migrated data, reports, mobile devices and integrations; defect list classified; no open defect that blocks deployment; agreed list of issues that may close after the phase, with owners and dates | Test lead, process owners | [status] | [comment] |
| 3.9 | End-user training material and step-by-step guides final | Guides used during the acceptance test without correction; course descriptions, instructor flow, data sets and exercises ready | Functional team leads | [status] | [comment] |
| 3.10 | Training plan approved (template [IDK-19](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/19-training-plan-and-course-description)) | Events, attendees, trainers and rooms; trainers booked for train-the-trainer | Training lead | [status] | [comment] |
| 3.11 | Next phase scheduled and resourced | Implement Solution plan: cutover planning, rehearsal dates, expert user training, readiness test, end-user training | Both PMs | [status] | [comment] |

 ## 4. Gate: Go Live Authorised

 Question: are the people, the data, the cutover plan and the support organisation ready, and is it safe to go?

 | # | Item | Evidence required | Owner | Status | Comment |
| --- | --- | --- | --- | --- | --- |
| 4.1 | Users attached to roles | Every go-live user exists in production with the correct role; list reconciled against the training attendance list | Technical analyst, security | [status] | [comment] |
| 4.2 | Expert users trained | Attendance record; feedback on the training material incorporated | Training lead | [status] | [comment] |
| 4.3 | Operational Readiness Test completed, documented and approved | Test report: expert users ran the acceptance scripts with the core team only advising; written confirmation on behalf of the business that solution and training are sufficient | Expert users, process owners | [status] | [comment] |
| 4.4 | End-user training delivered | Attendance per user against the training plan; catch-up sessions scheduled for absentees before go-live | Training lead | [status] | [comment] |
| 4.5 | Cutover plan prepared (template [IDK-20](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/20-cutover-plan-checklist-and-contingency)) | Plan at day level for the period around go-live and checklist at hour level for the go-live days, both covering data migration, time-critical configuration switches, communications, legacy decommissioning and support arrangements | [cutover manager] | [status] | [comment] |
| 4.6 | Contingency plan approved | Rollback plan stating how legacy would be reinstated, the point of no return, and who decides | Both PMs | [status] | [comment] |
| 4.7 | Cutover rehearsed | Full rehearsal with full data volumes completed; durations logged; plan corrected; further rehearsal held if the first exposed major gaps | [cutover manager] | [status] | [comment] |
| 4.8 | Load test signed off, if required | Load test report on concurrency, performance, reliability and volume, or recorded decision that none is required | Technical solution manager | [status] | [comment] |
| 4.9 | Go-live date confirmed against the business calendar | Date avoids business peaks and holidays and fits the financial period boundary; confirmed by finance and operations | Executive sponsor | [status] | [comment] |
| 4.10 | External parties informed | Communications to suppliers, customers, banks and other parties sent according to the communication plan ([IDK-05](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/05-communication-plan-and-stakeholder-analysis)) | Process owners | [status] | [comment] |
| 4.11 | Support arrangements ready | Support model agreed; expert users named per site and shift as first contact; help desk trained in basic administration; on-site go-live support scheduled for the agreed period | Customer PM | [status] | [comment] |
| 4.12 | Go-live resourced | Named people for every cutover task and support shift, on both sides, with deputies | Both PMs | [status] | [comment] |
| 4.13 | Open defects and risks accepted | List of open defects with workarounds and open Major and Critical risks, accepted by the steering group | Both PMs | [status] | [comment] |

 ## 5. Gate: Go Live Complete

 Question: is the business running on the new solution, is support in charge, and can the project be closed?

 | # | Item | Evidence required | Owner | Status | Comment |
| --- | --- | --- | --- | --- | --- |
| 5.1 | Cutover completed | Cutover checklist fully signed off; production backed up before release to users; migrated data validated by data owners | [cutover manager] | [status] | [comment] |
| 5.2 | Solution operating as agreed | Confirmation from each process owner that in-scope processes run in production; first period close or equivalent business cycle completed, if agreed as a criterion | Process owners | [status] | [comment] |
| 5.3 | Users can operate the solution | Support ticket trend reviewed; expert user feedback; follow-up training delivered where needed | Customer PM | [status] | [comment] |
| 5.4 | Business informed | Go-live communication sent to the organisation and external parties | Executive sponsor | [status] | [comment] |
| 5.5 | Residual issues planned | Residual issue list with owner, priority and date for each item | Both PMs | [status] | [comment] |
| 5.6 | Legacy decommissioned or scheduled | Legacy systems switched to read-only or retired according to the decommissioning strategy; retired interfaces switched off | Customer IT lead | [status] | [comment] |
| 5.7 | Support plan in place | Support arrangements activated; contacts and procedures known to users; update calendar for service updates and release updates owned by a named person | Customer IT lead | [status] | [comment] |
| 5.8 | Handover to support complete (template [IDK-22](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/22-handover-to-support)) | Handover document complete (customer information, contacts, checklist, third-party integrations, extensions and localisations, technical handover, environments); CRIM functional and test specifications in latest version; link to the process model; handover meeting held and recorded; basic data adjusted after go-live | Supplier PM | [status] | [comment] |
| 5.9 | Project evaluation done | Phase review held; lessons learned documented; benefit tracking handed to the sponsor with measures and dates | Both PMs | [status] | [comment] |
| 5.10 | Closure document agreed (template [IDK-24](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/24-project-closure-and-lessons-learned)) | Closure document listing residual issues and owners, signed by the steering group | Steering group | [status] | [comment] |

 ## 6. Gate decision record

 Copy this section once per gate.

 **Gate:** [gate name] **Phase closed:** [phase] **Meeting:** steering group no. [no.] **Date:** [YYYY-MM-DD]

 
### 6.1 Checklist summary

 | Status | Number of items | Item references |
| --- | --- | --- |
| Complete | [n] |   |
| In progress | [n] | [refs] |
| At risk | [n] | [refs] |
| Not started | [n] | [refs] |
| Not applicable | [n] | [refs, with reason] |

 Recommendation of the project managers: [approve / approve with conditions / do not approve], because [reason].

 
### 6.2 Decision

 | Decision | Mark one | Meaning |
| --- | --- | --- |
| Approved | [ ] | All items complete. Next phase starts as planned. |
| Approved with conditions | [ ] | Next phase may start. Listed conditions are closed by their dates; the steering group reviews them at its next meeting. |
| Not approved | [ ] | Next phase does not start. Listed items are completed and the gate is presented again on [YYYY-MM-DD]. |

 
### 6.3 Conditions and owners

 | # | Condition (checklist item) | What must be true to close it | Owner | Due | Closed on | Closure confirmed by |
| --- | --- | --- | --- | --- | --- | --- |
| Example: 1 | Item 3.1: warehouse roles not yet reviewed by the process owner | Warehouse manager signs the role catalogue; acceptance test scripts for receipt and counting re-run with the approved roles, results logged | Warehouse manager | [YYYY-MM-DD] | [YYYY-MM-DD] | Customer PM |
| [n] | [condition] | [closing criterion] | [name] | [YYYY-MM-DD] | [YYYY-MM-DD] | [name] |

 Consequences accepted with this decision (risk, cost, schedule): [text].

 
### 6.4 Release of the next phase

 | Item | Value |
| --- | --- |
| Next phase | [phase] |
| Start date | [YYYY-MM-DD] |
| Budget released | [amount or reference] |
| Resources confirmed | [yes/no, exceptions] |
| Baseline versions in force | Schedule [n.n], cost [n.n], solution scope [n.n], project scope [n.n] |

 ## Approval

 | Name | Role | Date | Signature |
| --- | --- | --- | --- |
| [name] | Chair, executive sponsor (customer) | [YYYY-MM-DD] | ______________________ |
| [name] | Sponsor (supplier) | [YYYY-MM-DD] | ______________________ |
| [name] | Steering group member, [area] | [YYYY-MM-DD] | ______________________ |
| [name] | Customer project manager | [YYYY-MM-DD] | ______________________ |
| [name] | Supplier project manager | [YYYY-MM-DD] | ______________________ |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/08-qualification-gate-checklists.md)

## Steering Group Pack Template (IDK-06)

Template IDK-06, version 1.0. Phase: All phases.

 ## How to use this template

 
- Part A (terms of reference) is written once, during Initiate Project, and approved at the first steering group meeting.
- Parts B to E are reused for every meeting: standing agenda, status report, key design decision paper (one per decision), minutes.
- The two project managers prepare the pack together and send it [agree in project] before the meeting. A steering group that reads papers at the table decides badly or not at all.
- Replace every `[bracketed field]`. Delete rows marked `Example:` once you have your own.
- A pack is done when each decision requested is stated as a question the steering group can answer with yes, no, or a choice between named options.

 | Field | Value |
| --- | --- |
| Template ID | IDK-06 |
| Phase | All phases |
| Owner | Customer project manager and supplier project manager (joint) |
| Approver | Steering group chair (executive sponsor) |
| Qualification gate | Project Initiated (terms of reference approved); used at every gate for the status report and gate decision |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [A1. Purpose](#a1-purpose)
- [A2. Responsibilities](#a2-responsibilities)
- [A3. Members](#a3-members)
- [A4. Working rules](#a4-working-rules)
- [C1. Summary](#c1-summary)
- [C2. Progress against plan](#c2-progress-against-plan)
- [C3. Milestones](#c3-milestones)
- [C4. Budget](#c4-budget)
- [C5. Top risks and issues](#c5-top-risks-and-issues)
- [C6. Decisions needed today](#c6-decisions-needed-today)
- [C7. Gate readiness](#c7-gate-readiness)
- [C8. Benefits and business readiness](#c8-benefits-and-business-readiness)
- [D1. Context](#d1-context)
- [D2. Options](#d2-options)
- [D3. Recommendation](#d3-recommendation)
- [D4. Impact of the recommendation](#d4-impact-of-the-recommendation)
- [D5. Decision](#d5-decision)
- [E1. Decisions](#e1-decisions)
- [E2. Actions](#e2-actions)
- [E3. Notes](#e3-notes)
- [Approval](#approval)

 ## Document control

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [name, role] | Terms of reference drafted |   |
| 1.0 | [YYYY-MM-DD] | [name, role] | Terms of reference approved | [steering group chair] |
| [meeting no.] | [YYYY-MM-DD] | [names] | Pack for steering group meeting [no.] |   |

 ## A1. Purpose

 The steering group is accountable for the money spent and for the work as a whole. It connects the project to the business and is the only body that can change scope, plan or budget.

 ## A2. Responsibilities

 
1. Monitor the project against its objectives and benefits.
2. Approve the project strategies (testing, training, communication, data, infrastructure, business change, legacy decommissioning).
3. Decide key design decisions brought by the project managers.
4. Authorise or reject changes to scope, plan and budget, including every modification and integration.
5. Set priority against competing initiatives and resolve resource conflicts.
6. Approve each qualification gate and release the next phase.
7. Act as visible champions of the project in their own business areas.

 The steering group does not manage the project day to day. That is the project managers' job.

 ## A3. Members

 | Name | Role in the company | Role in the steering group | Deputy allowed |
| --- | --- | --- | --- |
| [name] | [title] | Chair, executive sponsor | No |
| [name] | [title, supplier] | Supplier sponsor | [yes/no] |
| [name] | [head of business area] | Member, represents [area] | [yes/no] |
| [name] | Customer project manager | Reports, no vote | No |
| [name] | Supplier project manager | Reports, no vote | No |

 Members are senior representatives of the business areas most affected. Membership is a commitment of time: [agree in project] per meeting, plus reading the pack.

 ## A4. Working rules

 | Rule | Agreement |
| --- | --- |
| Meeting frequency | [agree in project], plus one meeting per gate. All dates booked at project start. |
| Quorum | [agree in project]. The chair must be present for a gate decision. |
| Pack distribution | Sent [agree in project] before the meeting |
| Decision method | [consensus, chair decides if none] |
| Decisions between meetings | [written procedure, for example by email with chair confirmation, recorded in the next minutes] |
| Minutes | Issued within [agree in project], with owned and dated actions |
| Extraordinary meeting | Called by the chair on request of either PM when a decision cannot wait |

 | # | Item | Lead | Purpose |
| --- | --- | --- | --- |
| 1 | Minutes and open actions from last meeting | Chair | Confirm, close actions |
| 2 | Status report (Part C) | Both PMs | Inform; questions |
| 3 | Top risks and issues, escalations | Customer PM | Decide on escalations |
| 4 | Key design decision papers (Part D) | Paper author | Decide |
| 5 | Change requests for authorisation ([IDK-07](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure)) | Both PMs | Authorise or reject |
| 6 | Benefits and business readiness | Executive sponsor, change lead | Review |
| 7 | Gate readiness, or gate decision when due ([IDK-08](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/08-qualification-gate-checklists)) | Both PMs | Decide at gate meetings |
| 8 | Summary of decisions and actions; next meeting | Chair | Confirm |

 **Meeting:** [no.] **Date:** [YYYY-MM-DD] **Reporting period:** [from] to [to] **Current phase:** [phase] **Next gate:** [gate], planned [YYYY-MM-DD]

 ## C1. Summary

 | Dimension | Status | Trend since last report | One-line explanation |
| --- | --- | --- | --- |
| Schedule | [green/amber/red] | [better/same/worse] | [explanation] |
| Budget | [green/amber/red] | [trend] | [explanation] |
| Scope | [green/amber/red] | [trend] | [explanation] |
| Resources | [green/amber/red] | [trend] | [explanation] |
| Solution quality | [green/amber/red] | [trend] | [explanation] |
| Business readiness | [green/amber/red] | [trend] | [explanation] |

 Green: on baseline. Amber: off baseline, recovery plan owned by the PMs. Red: off baseline, steering group decision needed.

 ## C2. Progress against plan

 | Workstream | Planned for this period | Achieved | Not achieved, and why | Planned for next period |
| --- | --- | --- | --- | --- |
| Example: Procurement and inventory | Solution workshops for requisition approval and receipt with putaway; draft guides | Both workshops held; requisition approval rules decided and recorded in the Book of Rules | Receipt guide not drafted: functional lead absent, no deputy | Draft receipt guide; first scenario test run with end-user permission sets |
| Example: Data migration | Second load of suppliers and parts | Load completed in Data Migration Manager; rejected records listed by cause | Duplicate suppliers still present in source | Cleansing of duplicates by procurement; third load |
| [workstream] | [planned] | [achieved] | [gap and reason] | [next] |

 ## C3. Milestones

 | Milestone | Baseline date | Forecast date | Status | Comment |
| --- | --- | --- | --- | --- |
| [milestone] | [YYYY-MM-DD] | [YYYY-MM-DD] | [done / on track / at risk / late] | [comment] |

 ## C4. Budget

 | Cost element | Baseline | Approved changes | Actual to date | Forecast to complete | Variance | Comment |
| --- | --- | --- | --- | --- | --- | --- |
| Supplier services | [amount] | [amount] | [amount] | [amount] | [amount] | [comment] |
| CRIM allowance | [amount] | [amount] | [amount] | [amount] | [amount] | [comment] |
| Contingency | [amount] | [amount] | [amount] | [amount] | [amount] | [comment] |
| [element] |   |   |   |   |   |   |

 ## C5. Top risks and issues

 | ID | Risk or issue | Rating or priority | Owner | Response and progress | Help needed from the steering group |
| --- | --- | --- | --- | --- | --- |
| Example: R-102 | Warehouse roles defined late; acceptance test may run with broad permission sets | Major | Technical analyst, security | Draft roles ready for review; process owner review outstanding | Warehouse manager to release a reviewer this period |
| [ID] | [description] | [rating] | [name] | [progress] | [request or none] |

 ## C6. Decisions needed today

 | # | Decision requested | Paper or change request | Recommended by PMs | Consequence of no decision |
| --- | --- | --- | --- | --- |
| Example: 1 | Approve option B in decision paper KDD-03 (one requisition authorisation rule set for both companies) | KDD-03 | Option B | Prototype approval moves; gate Solution Confirmed at risk |
| [n] | [decision as a yes/no or choice question] | [reference] | [recommendation] | [consequence] |

 ## C7. Gate readiness

 Gate: [gate name]. Planned decision date: [YYYY-MM-DD]. Detail in the gate checklist ([IDK-08](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/08-qualification-gate-checklists)).

 | Checklist items | Complete | In progress | At risk | Not started |
| --- | --- | --- | --- | --- |
| Count | [n] | [n] | [n] | [n] |

 Items at risk:

 | Item | Reason | Owner | Recovery action | Forecast |
| --- | --- | --- | --- | --- |
| [item] | [reason] | [name] | [action] | [YYYY-MM-DD] |

 ## C8. Benefits and business readiness

 | Benefit ([IDK-02](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/02-project-scope-statement)) | Owner | Still achievable as planned | Comment |
| --- | --- | --- | --- |
| [ID, benefit] | [name] | [yes / at risk / no] | [comment] |

 Change management check, reported by the change lead: change plan with owners [yes/no], organisation design adjusted to new capabilities [yes/no/in progress], policies and procedures being updated [yes/no/in progress], user advocacy activities running [yes/no].

 One paper per decision. Keep it short enough to be read before the meeting; detail goes in an appendix.

 **Paper ID:** KDD-[nn] **Title:** [decision in one line] **Author:** [name, role] **Date:** [YYYY-MM-DD] **Decision needed by:** [YYYY-MM-DD]

 ## D1. Context

 | Item | Content |
| --- | --- |
| Process area and process | [for example: procurement, purchase requisition approval] |
| What needs deciding, as a question | [question] |
| Why it cannot be decided inside the functional team | [for example: affects more than one business area, needs a modification, changes policy] |
| What the functional team, the solution architect and the PMs concluded | [summary of steps already taken on the change control ladder] |
| Constraints | [legal, audit, contractual, timing] |

 ## D2. Options

 |   | Option A: [name] | Option B: [name] | Option C: [name] |
| --- | --- | --- | --- |
| Description | Example: Keep two authorisation rule sets, one per company, using standard configuration | Example: One rule set for both companies; company B changes its approval policy | Example: Modification to route approvals by a custom rule |
| Uses standard functionality | Yes | Yes | No |
| Advantages | [pros] | [pros] | [pros] |
| Disadvantages | [cons] | [cons] | [cons] |
| Impact on scope, schedule, cost | [impact] | [impact] | [impact] |
| Impact on CRIM and on future service and release updates | [impact] | [impact] | [impact] |
| Impact on data, training, testing | [impact] | [impact] | [impact] |
| Business change required | [impact] | [impact] | [impact] |

 Doing nothing is always listed as an option when it is possible.

 ## D3. Recommendation

 | Item | Content |
| --- | --- |
| Recommended option | [option] |
| Reasoning | [why, in business terms] |
| Who supports it | [functional team lead, process owner, solution architect, PMs] |
| Dissenting view, if any | [who and why; stated fairly] |

 ## D4. Impact of the recommendation

 | Area | Impact | Owner of follow-up |
| --- | --- | --- |
| Baselines (scope, schedule, cost) | [impact; change request reference if any] | [name] |
| Book of Rules and process model | [sections to update] | [name] |
| Policies and procedures | [documents to update] | [name] |
| Communication | [who must be told, by whom] | [name] |

 ## D5. Decision

 | Decision | Date | Decided by | Conditions |
| --- | --- | --- | --- |
| [option approved / rejected / returned for more work] | [YYYY-MM-DD] | Steering group, meeting [no.] | [conditions] |

 **Meeting:** [no.] **Date, time, place:** [details] **Chair:** [name] **Minutes by:** [name]

 | Present | Apologies | Deputies |
| --- | --- | --- |
| [names] | [names] | [name for name] |

 ## E1. Decisions

 | # | Decision | Reference | Conditions |
| --- | --- | --- | --- |
| Example: D-07 | Option B of KDD-03 approved: one requisition authorisation rule set for both companies | KDD-03 | Head of procurement updates the approval policy for company B before acceptance test |
| [ID] | [decision] | [paper, change request, gate] | [conditions] |

 ## E2. Actions

 Every action has one owner, present in the meeting or informed the same day, and a date.

 | # | Action | Owner | Due | Status |
| --- | --- | --- | --- | --- |
| Example: A-21 | Release a warehouse reviewer for the permission set review | Warehouse manager | [YYYY-MM-DD] | Open |
| [ID] | [action] | [name] | [YYYY-MM-DD] | [open / done / overdue] |

 ## E3. Notes

 | Agenda item | Key points discussed |
| --- | --- |
| [item] | [points, short] |

 **Next meeting:** [date, time, place]. **Pack due:** [YYYY-MM-DD].

 ## Approval

 Terms of reference (Part A):

 | Name | Role | Date | Signature |
| --- | --- | --- | --- |
| [name] | Chair, executive sponsor (customer) | [YYYY-MM-DD] | ______________________ |
| [name] | Sponsor (supplier) | [YYYY-MM-DD] | ______________________ |
| [name] | Steering group member, [area] | [YYYY-MM-DD] | ______________________ |

 Minutes of meeting [no.] (Part E):

 | Name | Role | Date | Signature |
| --- | --- | --- | --- |
| [name] | Chair | [YYYY-MM-DD] | ______________________ |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/06-steering-group-pack.md)

## Communication Plan and Stakeholder Analysis Template (IDK-05)

Template IDK-05, version 1.0. Phase: Initiate Project.

 ## How to use this template

 
- Write it during Initiate Project, after the project organisation ([IDK-03](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/03-project-organisation-and-raci)) is known. Do the stakeholder analysis first (sections 1 to 4), then the plan (sections 5 to 7). The analysis tells you whom the plan is for.
- The customer project manager owns it, with the change lead if one is named. The supplier project manager adds the project-internal meetings and reports.
- Replace every `[bracketed field]`. Delete rows marked `Example:` once you have your own.
- Section 3 contains opinions about named people. Keep a restricted version with sections 2 to 4 and circulate the rest.
- It is done when every stakeholder group in the grid appears as an audience in the plan, every communication has a named sender, and each line says how feedback comes back.
- Review it at every gate. Audiences change: early on it is managers and the core team, before go-live it is every user and some external parties.

 | Field | Value |
| --- | --- |
| Template ID | IDK-05 |
| Phase | Initiate Project |
| Owner | Customer project manager (with supplier project manager support) |
| Approver | Executive sponsor |
| Qualification gate | Project Initiated |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Stakeholder analysis: method](#1-stakeholder-analysis-method)
- [2. Stakeholder list](#2-stakeholder-list)
- [3. Power and interest grid](#3-power-and-interest-grid)
- [4. Understanding key stakeholders](#4-understanding-key-stakeholders)
- [5. Communication objectives](#5-communication-objectives)
- [6. Communication plan: the seven questions](#6-communication-plan-the-seven-questions)
- [7. Meeting calendar](#7-meeting-calendar)
- [8. Channels and ownership](#8-channels-and-ownership)
- [9. Communication log](#9-communication-log)
- [Approval](#approval)

 ## Document control

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [name, role] | First draft |   |
| 1.0 | [YYYY-MM-DD] | [name, role] | Baseline for gate Project Initiated | [executive sponsor] |

 ## 1. Stakeholder analysis: method

 Three steps, repeated at each gate:

 
1. **Identify.** List every person or group that is affected by the project, can influence it, or has an interest in its success or failure. Include external parties.
2. **Prioritise.** Place each on the power and interest grid in section 3. The position decides the strategy.
3. **Understand.** For the key stakeholders, answer the questions in section 4. Ask them directly where possible; a conversation is also the first act of engagement.

 ## 2. Stakeholder list

 | ID | Stakeholder (person or group) | Organisation, department | How the project affects them | Power | Interest | Current attitude | Relationship owner |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: SH-01 | Head of procurement | Purchasing | Owns the future purchasing process and the benefit tied to it; loses local purchasing habits at two sites | High | High | Supporter | Executive sponsor |
| Example: SH-02 | Warehouse shift leaders | Logistics, [site] | Move from paper picking lists to handheld scanning; their teams are the largest user group | Low | High | Neutral, worried about pace at peak times | Functional team lead, inventory |
| Example: SH-03 | Finance director | Finance | Needs period close unaffected by go-live; approves segregation of duties in permission sets | High | Low at present | Neutral | Customer PM |
| Example: SH-04 | Key suppliers receiving purchase orders | External | New order layout and order numbers; changed confirmation routine | Low | Low | Unaware | Head of procurement |
| [ID] | [stakeholder] | [department] | [effect] | [High/Low] | [High/Low] | [champion / supporter / neutral / critic / blocker] | [name] |

 Power means ability to stop, slow or change the project. Interest means how much the outcome matters to them. Rate what is true today, not what you wish.

 ## 3. Power and interest grid

 Place stakeholder IDs in the cells.

 |   | Low interest | High interest |
| --- | --- | --- |
| **High power** | **Keep satisfied.** Give enough to keep them comfortable; do not flood them. Short, factual updates. Consult before decisions that touch their area. IDs: [SH-..] | **Engage closely.** Involve in decisions, meet in person, make every effort to keep them on board. Steering group members belong here. IDs: [SH-..] |
| **Low power** | **Monitor.** Watch for changes in position. Minimal effort: general news only. IDs: [SH-..] | **Keep informed.** Regular information and a way to ask questions. They often spot practical problems first and can become advocates. IDs: [SH-..] |

 Movement to watch: [for example: finance director moves to high interest before period close and go-live; suppliers move to high interest in the weeks before cutover].

 ## 4. Understanding key stakeholders

 Complete for each stakeholder in "engage closely" and "keep satisfied". One block per person.

 **Stakeholder:** [name, role]. **Interviewed by:** [name]. **Date:** [YYYY-MM-DD].

 | Question | Answer |
| --- | --- |
| What financial or emotional interest do they have in the outcome? Is it positive or negative? | [answer] |
| What motivates them most in their job? | [answer] |
| What information do they want from the project, and in what form do they prefer it? | [answer] |
| What is their current opinion of the project? Is it based on good information? | [answer] |
| Who influences their opinions in general, and who influences their opinion of this project? Are those people stakeholders too? | [answer] |
| If they are not positive, what would win their support? | [answer] |
| If they cannot be won, how will their opposition be managed? | [answer] |
| Whom do they influence in turn? | [answer] |

 Resulting actions:

 | Action | Owner | Due |
| --- | --- | --- |
| Example: Walk the finance director through the go-live date options against the period calendar before the steering group paper is sent | Customer PM | [YYYY-MM-DD] |
| [action] | [name] | [YYYY-MM-DD] |

 ## 5. Communication objectives

 | Objective | How we will know it works |
| --- | --- |
| Everyone affected knows why the project exists and what changes for them | [for example: short pulse questions after site briefings] |
| Decisions are understood where they land, including the reason | Reasoning recorded with each decision and included in the message |
| Rumours are answered fast | Questions channel answered within [agree in project] |
| [objective] | [measure] |

 Principles: talk about benefits for the audience, not features of the system. Say what is not yet decided. One message, one sender. Line managers deliver news that changes someone's job; the project supports them with material.

 ## 6. Communication plan: the seven questions

 Each line answers: who receives, who sends, why, when and how often, what content, how it is delivered, how feedback is gathered.

 | # | Who receives | Who sends | Why | When, how often | What content | How delivered | How feedback is gathered |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: C-01 | Steering group | Both PMs | Decisions and gate approval | [agree in project], papers sent in advance | Status report, key design decision papers, change requests ([IDK-06](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/06-steering-group-pack)) | Meeting with pack | Decisions and actions in minutes |
| Example: C-02 | All employees at in-scope sites | Executive sponsor | Explain purpose, timeline, what changes and what does not | At project start and after each gate | Short message in business language; link to project page | Site meeting and intranet | Questions mailbox; questions and answers published |
| Example: C-03 | Warehouse operators and shift leaders | Warehouse manager, with expert users | Prepare for handheld scanning and the new receipt routine | From acceptance test onward, [frequency agreed in project] | What changes in the daily routine, training dates, who the expert user on each shift is | Shift briefing, demonstration on the device | Expert users collect concerns and bring them to the functional team |
| Example: C-04 | Key suppliers | Head of procurement | Avoid rejected orders and late confirmations after go-live | Before cutover, date from cutover plan | New order layout, order numbering, contact for questions, cutover freeze dates | Letter or email from the buyer responsible | Buyer follows up by phone with the largest suppliers |
| Example: C-05 | Help desk and support partner | Customer PM | Readiness for first-line support | Before go-live and at handover | Support model, expert user list, basic administration tasks, known residual issues | Briefing and handover document | Open questions logged and answered before go-live |
| [ID] | [audience] | [sender] | [purpose] | [timing] | [content] | [channel] | [feedback route] |

 ## 7. Meeting calendar

 | Meeting | Purpose | Chair | Participants | Frequency | Input | Output |
| --- | --- | --- | --- | --- | --- | --- |
| Project team meeting | Coordinate workstreams, review plan, risks and issues | Customer PM | PMs, functional leads, solution architect, technical leads | Weekly | Workstream status, plan, risk register, issue log | Action list, updated plan |
| PM-to-PM meeting | Align on plan, resources, upcoming customer tasks, commercial matters | Alternating | Both PMs | Weekly | Tracker, budget status | Agreed positions, escalations |
| Project review | Ongoing control by the PMs; establishes milestone status | Supplier PM | Both PMs, workstream leads as needed | [agree in project] | Master implementation plan, tracker | Milestone status for the status report |
| Steering group | Progress, escalations, key design decisions, change authorisation, gate approval | Executive sponsor | Steering group members ([IDK-03](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/03-project-organisation-and-raci)) | [agree in project], plus each gate | Steering group pack ([IDK-06](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/06-steering-group-pack)), sent in advance | Minutes with owned actions, decisions, gate decision record |
| Phase review | Look back at the phase: what worked, what to change; after go-live, the project evaluation | Both PMs | Core team, sponsors | End of each phase; final review after go-live | Tracker, risk and issue history, test results | Lessons learned, input to next phase plan or closure document |
| Defect triage | Classify and assign defects during test cycles | Test lead | Test lead, functional leads, application consultants | [daily during test cycles, agree in project] | Test tracker | Classified defects with owner and date |
| Cutover status review | Control of the go-live event | [cutover manager] | Cutover team | Short and frequent during cutover, [agree in project] | Cutover checklist | Updated checklist, go or stop decisions |
| [meeting] | [purpose] | [role] | [participants] | [frequency] | [input] | [output] |

 Meeting rules: agenda in the invitation; decisions and actions recorded with owner and date; records stored in [location] within [agree in project].

 ## 8. Channels and ownership

 | Channel | Used for | Owner | Not used for |
| --- | --- | --- | --- |
| Example: Project page on intranet | Timeline, news, questions and answers, training calendar | Change lead | Decisions that affect individuals |
| Example: Project collaboration space | Working documents, action lists | Both PMs | Communication to the wider business |
| [channel] | [use] | [name] | [limits] |

 Project identity: [project name, short description used in all messages, visual identity if any].

 ## 9. Communication log

 | Date | Communication (ID from section 6) | Sent by | Audience reached | Feedback received | Follow-up |
| --- | --- | --- | --- | --- | --- |
| [YYYY-MM-DD] | [ID] | [name] | [audience] | [summary] | [action, owner] |

 ## Approval

 | Name | Role | Date | Signature |
| --- | --- | --- | --- |
| [name] | Executive sponsor (customer) | [YYYY-MM-DD] | ______________________ |
| [name] | Customer project manager | [YYYY-MM-DD] | ______________________ |
| [name] | Change lead | [YYYY-MM-DD] | ______________________ |
| [name] | Supplier project manager | [YYYY-MM-DD] | ______________________ |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/05-communication-plan-and-stakeholder-analysis.md)

## Risk Register and Issue Log Template (IDK-04)

Template IDK-04, version 1.0. Phase: All phases.

 ## How to use this template

 
- Set it up during Initiate Project and keep it alive until the closure document is signed. A register that is only opened before a steering group meeting is a report, not a control.
- The customer project manager owns it. The supplier project manager contributes risks from the delivery side. Every team member may raise an entry.
- Section 4 is starter content: risks that recur in ERP implementations. Keep the ones that apply, rewrite them for your project, delete the rest. Do not present the starter list as your risk analysis.
- A risk is something that may happen. An issue has happened. When a risk occurs, close it in the register and open it in the issue log with a reference.
- It is done for the first gate when the scales are agreed, every open risk has one named owner and a response, and the escalation rule in section 6 is accepted by the steering group.

 | Field | Value |
| --- | --- |
| Template ID | IDK-04 |
| Phase | All phases |
| Owner | Customer project manager (with supplier project manager support) |
| Approver | Steering group |
| Qualification gate | Project Initiated (register and process in place); reviewed at every later gate |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Risk process](#1-risk-process)
- [2. Scales](#2-scales)
- [3. Rating matrix](#3-rating-matrix)
- [4. Risk register](#4-risk-register)
- [5. Issue log](#5-issue-log)
- [6. Escalation rule](#6-escalation-rule)
- [7. Review rhythm](#7-review-rhythm)
- [Approval](#approval)

 ## Document control

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [name, role] | Process, scales and starter register |   |
| 1.0 | [YYYY-MM-DD] | [name, role] | Baseline for gate Project Initiated | [steering group chair] |

 ## 1. Risk process

 | Step | What happens | Who | When |
| --- | --- | --- | --- |
| 1. Identify | Risks are collected in workshops, in the weekly project team meeting and from each phase review. Each is written as cause, event, effect: "Because [cause], [event] may happen, leading to [effect]." | Anyone; logged by the PMs | Continuous |
| 2. Assess | Probability and impact are rated with the scales in section 2. The rating comes from section 3. | PMs with the person who raised it | Within [agree in project] of logging |
| 3. Plan response | One response type is chosen: avoid, reduce, transfer, accept. For reduce: concrete actions. For accept: a stated trigger and a fallback. | Risk owner | Before the next project team meeting |
| 4. Assign and act | One named owner per risk. Actions enter the project plan with dates, like any other task. The owner reports progress; the PMs check that actions are actually performed. | Risk owner, PMs | Reviewed weekly; top risks at every steering group |

 Closing a risk requires a reason: occurred (moved to issue log), no longer possible, or reduced to a level the steering group accepts.

 ## 2. Scales

 Ratings are described in words so that two people rate the same risk the same way.

 
### 2.1 Probability

 | Rating | Meaning |
| --- | --- |
| Low | Would surprise the team. No sign of the cause today. |
| Medium | Could reasonably happen. The cause is present but under some control. |
| High | Expected to happen unless something changes. Early signs are already visible. |

 
### 2.2 Impact

 | Rating | Schedule | Cost | Solution quality and business operation |
| --- | --- | --- | --- |
| Low | Absorbed inside the phase; no milestone moves | Absorbed inside the workstream budget | Inconvenience; a workaround exists and users accept it |
| Medium | A milestone moves but the gate date holds | Needs contingency released by the sponsor | A process works with a manual step, or a benefit is delayed |
| High | A gate or the go-live date moves | Needs a budget decision by the steering group | A business-critical process cannot run, or data cannot be trusted |

 Project-specific definitions agreed for this project: [add or adjust].

 ## 3. Rating matrix

 | Probability \ Impact | Low | Medium | High |
| --- | --- | --- | --- |
| High | Moderate | Major | Critical |
| Medium | Minor | Moderate | Major |
| Low | Minor | Minor | Moderate |

 | Rating | Handling |
| --- | --- |
| Critical | Reported to the steering group with a response plan. Owner at sponsor or steering group level. |
| Major | In the top-risk list of the status report. Owner at PM or process owner level. |
| Moderate | Managed by the PMs. Reviewed weekly. |
| Minor | Logged and reviewed at each phase end. |

 ## 4. Risk register

 Columns: P = probability, I = impact. Status: open, reducing, accepted, occurred, closed.

 
### 4.1 Project-specific risks

 | ID | Raised | Risk (cause, event, effect) | Area | P | I | Rating | Response type | Response actions | Owner | Next review | Status |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: R-101 | [YYYY-MM-DD] | Because supplier and part data sit in two legacy systems with different numbering, duplicate suppliers may be loaded, leading to split purchase history and wrong payment terms on purchase orders | Data, procurement | High | Medium | Major | Reduce | Procurement data steward merges duplicates in the source before load cycle [n]; match rule agreed; validation query run after every load in Data Migration Manager | Procurement data steward | [YYYY-MM-DD] | Reducing |
| Example: R-102 | [YYYY-MM-DD] | Because warehouse roles are defined late, the acceptance test may be run with broad permission sets, leading to access problems discovered only at go-live | Security, inventory | Medium | High | Major | Reduce | Functional roles for warehouse drafted before the security-and-data test cycle; testers log in with end-user permission sets only | Technical analyst, security | [YYYY-MM-DD] | Open |
| [ID] | [YYYY-MM-DD] | [risk] | [area] | [P] | [I] | [rating] | [type] | [actions] | [name] | [YYYY-MM-DD] | [status] |

 
### 4.2 Starter content: risks that recur in implementation projects

 Listed roughly from most to least damaging. Rate each for your own project; the P and I columns are left empty on purpose.

 | ID | Risk | Typical early sign | Response that works | P | I | Suggested owner |
| --- | --- | --- | --- | --- | --- | --- |
| S-01 | Senior management is not visibly committed | Steering group members send deputies; decisions wait | Steering group members act as champions in their own areas; attendance and decisions are minuted |   |   | Executive sponsor |
| S-02 | The wrong people are on the team, or the right people are not released | Workshops attended by whoever is free; core team answers operational calls during sessions | Key people with authority to decide; backfill agreed in writing ([IDK-03](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/03-project-organisation-and-raci) section 6); extra capacity planned for peaks |   |   | Executive sponsor |
| S-03 | Project management is weak | Plan not updated; same issues reappear; meetings without actions | Realistic plans; plan, do, review cycle per team every week; short whole-team stand-up; risks and issues worked actively |   |   | Both PMs |
| S-04 | Scope grows without decision | "Small" additions agreed in workshops; consultants building undocumented items | Scope baselined in the plan and scope statement and signed by the steering group; every change documented and communicated ([IDK-07](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure)) |   |   | Both PMs |
| S-05 | Pressure for modifications and for keeping legacy interfaces | Requests to make the new system look like the old one | From the first day, modifications and integrations need steering group authorisation; standard functionality is tried first |   |   | Steering group |
| S-06 | Resistance to change | Rumours, low workshop engagement, requests driven by habit | Communication strategy and plan; messages about benefits for each group; the system is not modified to soothe users |   |   | Change lead |
| S-07 | Other projects compete for the same people and attention | Core team pulled into other initiatives | Sponsor keeps this project among the top business priorities and resolves conflicts at steering group |   |   | Executive sponsor |
| S-08 | The solution does not meet the need or the quality expected | Tests designed only by the project team; decisions not reviewed | Right team; test design involves the wider business; steering group reviews major decisions; unit tests, then end-to-end tests by the team, then by end users |   |   | Customer PM |
| S-09 | Data migration fails or arrives late | Data sources unknown; cleansing not started; first load attempted late | Identify data and sources early; start cleansing early; documented strategy; trained technical team; several full load iterations |   |   | Customer data lead |
| S-10 | End users are not trained or do not accept the solution | No training plan; trainers not named | Plan who is trained, in what, when and by whom; train the trainer; expert users teach their colleagues |   |   | Customer PM |
| S-11 | Go-live fails | Cutover plan exists only in the supplier's head; no rehearsal | Documented and approved cutover plan; rehearsed more than once with full data volumes; rollback plan with a point of no return |   |   | Both PMs |
| S-12 | Teething problems after go-live overwhelm the business | Help desk unprepared; no local presence | Training that shows each user what they personally gain; support present on site; expert users as first contact; help desk trained in basic administration |   |   | Customer PM |
| S-13 | Benefits are not realised | Business case not looked at after approval | Time-bound benefits in the business case; sponsor accountable; reviewed at every steering group |   |   | Executive sponsor |
| S-14 | Tailoring blocks future updates | CRIM log grows; no one asks how objects behave at the next release update | Update cadence discussed at project start; technical solution manager reviews each CRIM item for update impact |   |   | Technical solution manager |

 ## 5. Issue log

 An issue is a fact that needs action now. It has a priority, not a probability.

 | Priority | Meaning |
| --- | --- |
| High | Stops a workstream or threatens a milestone. Needs a resolution path within [agree in project]. |
| Medium | Slows work; a workaround exists. |
| Low | Does not affect the plan. Fixed when convenient. |

 | ID | Raised | Raised by | Issue description | Area | Priority | Impact if unresolved | Owner | Agreed action | Due | Status | Resolution and date | Linked risk or change request |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Example: I-014 | [YYYY-MM-DD] | Functional team lead, procurement | Approved authorisation rules for purchase requisitions differ between the two companies; the Book of Rules assumes one rule set | Procurement | High | Prototype scenario for requisition approval cannot be finalised | Head of procurement | Decide on one rule set or document both; decision paper to PMs | [YYYY-MM-DD] | Open |   | [CR reference if raised] |
| Example: I-015 | [YYYY-MM-DD] | Technical analyst, integrations | Third-party transport system has no test instance available for integration testing | Integrations | Medium | Integration INT-03 tested late, risk to acceptance test entry | Customer IT lead | Request test instance from vendor; interim test with recorded messages | [YYYY-MM-DD] | In progress |   | R-[n] |
| [ID] | [YYYY-MM-DD] | [name] | [issue] | [area] | [priority] | [impact] | [name] | [action] | [YYYY-MM-DD] | [status] | [resolution] | [reference] |

 Defects found in testing are not logged here. They live in the test tracker with their own classification (cause, blocks deployment, contractual, owner, closure date). Only a defect that threatens a milestone is lifted into this log.

 ## 6. Escalation rule

 | Situation | Escalated to | By | How fast |
| --- | --- | --- | --- |
| Risk rated Critical, or any risk whose response needs budget, scope or date change | Steering group | Both PMs, through the sponsor | Next steering group; extraordinary meeting if the decision cannot wait |
| High-priority issue not resolved by its due date | Executive sponsor | Customer PM | [agree in project] |
| Issue where the two PMs disagree | Both sponsors | Either PM, after telling the other | [agree in project] |
| Issue blocked by a person or department outside the project | Executive sponsor | Customer PM | [agree in project] |
| Any issue whose resolution changes a baseline | Change control ([IDK-07](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure)) | Issue owner | Before work continues |

 An escalation is written: the issue, the options considered, the recommendation, the decision needed and the date it is needed by. Putting it in writing often settles it before the meeting.

 ## 7. Review rhythm

 | Review | Participants | Scope |
| --- | --- | --- |
| Weekly project team meeting | PMs, workstream leads | New entries, overdue actions, Major and Critical risks, High issues |
| Steering group | Steering group | Top risks and issues, escalations, trend since last meeting |
| Phase review | PMs, sponsors | Full register; lessons feeding the next phase |

 ## Approval

 | Name | Role | Date | Signature |
| --- | --- | --- | --- |
| [name] | Executive sponsor (customer) | [YYYY-MM-DD] | ______________________ |
| [name] | Customer project manager | [YYYY-MM-DD] | ______________________ |
| [name] | Supplier project manager | [YYYY-MM-DD] | ______________________ |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/04-risk-register-and-issue-log.md)

## Project Organisation and RACI Template (IDK-03)

Template IDK-03, version 1.0. Phase: Initiate Project.

 ## How to use this template

 
- Write it during Initiate Project, as soon as the sponsors are named. It is referenced by the Project Management Plan ([IDK-01](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/01-project-management-plan) section 6.2) and forms part of the project scope baseline.
- Each project manager fills in their own side. The customer project manager collects the time commitment and backfill agreements, because only the customer can release its own people.
- Replace every `[bracketed field]`. Delete rows marked `Example:` once you have your own.
- It is done when every role has a name, every core team member has a released share of time confirmed by their line manager, and every deliverable in the RACI has exactly one A.
- Revisit it at every gate. People change during a long project; the document must not lag behind.

 | Field | Value |
| --- | --- |
| Template ID | IDK-03 |
| Phase | Initiate Project |
| Owner | Customer project manager and supplier project manager (joint) |
| Approver | Steering group |
| Qualification gate | Project Initiated |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Organisation chart](#1-organisation-chart)
- [2. Governance bodies](#2-governance-bodies)
- [3. Role descriptions, customer side](#3-role-descriptions-customer-side)
- [4. Role descriptions, supplier side](#4-role-descriptions-supplier-side)
- [5. RACI matrix by deliverable](#5-raci-matrix-by-deliverable)
- [6. Time commitment and backfill agreement](#6-time-commitment-and-backfill-agreement)
- [7. Focus groups](#7-focus-groups)
- [8. Expert users](#8-expert-users)
- [Approval](#approval)

 ## Document control

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [name, role] | First draft |   |
| 1.0 | [YYYY-MM-DD] | [name, role] | Baseline for gate Project Initiated | [steering group chair] |

 ## 1. Organisation chart

 Text form, so it survives copy and paste. Indentation shows the reporting line inside the project, not in the company.

 
```
Steering group
  Chair: [name], executive sponsor (customer)
  Members: [name], sponsor (supplier)
           [name], [head of business area most affected]
           [name], [head of business area most affected]
           [name], customer project manager
           [name], supplier project manager
  |
  +-- Customer project manager: [name]
  |     +-- Functional team, [area, e.g. procurement and inventory]: lead [name]
  |     |     +-- Core team members: [names]
  |     |     +-- Expert users: [names]
  |     +-- Functional team, [area, e.g. finance]: lead [name]
  |     +-- Technical analysts: security [name], data migration [name],
  |     |                       integrations [name], reports [name]
  |     +-- Change lead: [name]
  |     +-- Test lead: [name]
  |     +-- Focus groups (time-boxed): [see section 7]
  |
  +-- Supplier project manager: [name]
        +-- Solution architect: [name]
        +-- Technical solution manager: [name]
        +-- Application consultants: [area: name], [area: name]
        +-- Technical resources and developers: [names]
        +-- Systems engineer: [name]
        +-- Account manager: [name] (commercial matters, outside the delivery line)```

 The two project managers work as a pair. They meet weekly without the teams, and neither surprises the other in front of the steering group.

 ## 2. Governance bodies

 | Body | Purpose | Members | Chair | Meets |
| --- | --- | --- | --- | --- |
| Steering group | Accountable for spend and for the work as a whole. Links the project to the business, approves strategies and key design decisions, authorises changes to scope, plan and budget, signs off each gate. | [names] | Executive sponsor | [agree in project], plus each gate |
| Project management | Day-to-day control of plan, resources, risks and issues | Both PMs | Alternating | Weekly |
| Project team | Coordination across workstreams | PMs, functional leads, solution architect, technical leads | Customer PM | Weekly |
| Design authority | Reviews alternatives before they reach the PMs in change control | Solution architect, technical solution manager, [customer architect or IT lead] | Solution architect | On demand |

 Sponsor and project manager are different jobs. The sponsor works like a chairman: secures governance, owns the business case and is accountable for the benefits. The project manager works like a managing director: runs the project every day. The sponsor does not manage the project, and the project manager does not own the business case.

 ## 3. Role descriptions, customer side

 | Role | Named person | Main responsibilities | Authority |
| --- | --- | --- | --- |
| Executive sponsor | [name] | Owns business case and benefit realisation. Chairs the steering group. Keeps the project among the top business priorities when other initiatives compete. Decides whether a change is tabled at the steering group. | Releases contingency; final customer escalation point |
| Customer project manager | [name] | Plans and tracks all customer tasks. Owns risk register, issue log, communication plan and the strategy documents. Secures people and rooms. Manages testing. | Approves configuration and report specifications; approves deliverables within baseline |
| Process owner | [name per area] | Owns the future process and the measurable benefit tied to it. Accepts the solution for the area. | Accepts the area at acceptance test |
| Functional team lead | [name per area] | Leads the team that designs, tests, trains and goes live for an area. Writes down the reasoning behind each decision, not only the decision. | Decides within the area without referring upward; this empowerment is confirmed by the sponsor in writing |
| Functional team member (core team) | [names] | Workshops, Book of Rules review, test scripts, step-by-step guides, data validation, training delivery | Recommends |
| Technical analyst, security | [name] | Roles, permission sets, user administration, segregation of duties checks with finance | Builds and maintains |
| Technical analyst, data migration | [name] | Legacy extracts, mapping with consultants, migration jobs in Data Migration Manager, load iterations | Builds and maintains |
| Technical analyst, integrations, reports and events | [name] | Interface register, integration testing with third parties, report layouts, lobbies, workflows | Builds and maintains |
| Change lead | [name] | Organisational change plan, user advocacy, updated policies and procedures. This is customer work; the project managers check that it exists. | Owns change plan |
| Test lead | [name] | Test strategy, test plan, defect triage, test reporting | Runs triage |
| Security lead | [name] | Roles, permission sets, segregation of duties, access for integrations and service accounts | Approves permission set design |
| Training lead | [name] | Training strategy, training plan, course material, train-the-trainer, attendance and evaluation records | Owns training plan |
| Customer IT lead | [name] | Environments, infrastructure, integrations landscape, update calendar during the project | Owns environment decisions |
| Cutover manager | [name] | Cutover plan, hour-by-hour checklist, rehearsals, contingency plan | Runs cutover |
| System owner (after go-live) | [name] | Owns the solution in operation, the update calendar and the CRIM log after project closure | Decides on changes after closure |
| Expert user | [names per site and area] | See section 8 | First contact after go-live |

 ## 4. Role descriptions, supplier side

 | Role | Named person | Main responsibilities |
| --- | --- | --- |
| Sponsor | [name] | Executive counterpart to the customer sponsor. Secures supplier resources. Escalation point. |
| Project manager | [name] | Owns the project management plan, scope statement, master implementation plan and workshop plan. Manages supplier delivery, cost and quality. |
| Solution architect | [name] | Keeps the solution coherent across business areas. Owns the process models. Challenges key design decisions before they become CRIM requests. |
| Technical solution manager | [name] | Owns the overall technical solution and the technical design of CRIM objects, with a view to service updates and release updates. |
| Application consultant | [name per area] | Facilitates workshops, configures in the web client, coaches the functional team, reviews guides and scripts. |
| Technical resource, developer | [names] | Builds and unit tests integrations, modifications, reports and configurations in Build Place. |
| Systems engineer | [name] | Environments, deliveries between Build Place and Use Place, technical cutover tasks. |
| Account manager | [name] | Commercial relationship, contract changes after an approved change request. |

 ## 5. RACI matrix by deliverable

 R = does the work. A = accountable, exactly one per row. C = consulted before. I = informed after.

 Columns: ES executive sponsor, SG steering group, CPM customer PM, SPM supplier PM, PO process owner, FT functional team, TA technical analysts, SA solution architect, TSM technical solution manager, AC application consultants.

 | Deliverable | ES | SG | CPM | SPM | PO | FT | TA | SA | TSM | AC |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Project management plan | C | A | C | R | I | I | I | C | C | I |
| Project scope statement | C | A | C | R | C | C | I | C | C | I |
| Risk register and issue log | I | I | A/R | R | C | C | C | C | C | C |
| Communication plan | C | I | A/R | C | C | I | I | I | I | I |
| Book of Rules documents | I | I | C | C | A | R | I | C | I | R |
| Process model and scope | I | I | C | C | C | C | I | A/R | C | R |
| Prototype | I | I | C | A | C | C | C | C | C | R |
| Interface register | I | I | A | C | I | C | R | C | R | C |
| Data migration plan and load iterations | I | I | A | C | C | R | R | I | C | R |
| Roles and permission sets | I | I | A | I | C | R | R | I | C | C |
| CRIM specifications | I | I | C | A | C | R | C | C | R | R |
| Approval of integration and modification specifications | C | A | R | C | R | C | C | C | C | I |
| Test strategy, scripts and execution | I | I | A | C | C | R | R | I | I | C |
| Step-by-step guides and training material | I | I | A | I | C | R | I | I | I | C |
| Solution Acceptance Test result | C | A | R | C | R | R | R | C | C | C |
| Cutover plan, checklist and rollback plan | C | A | R | R | C | R | R | C | R | C |
| Operational Readiness Test result | C | A | R | I | R | C | C | I | I | C |
| Handover to support | I | I | C | A/R | I | C | C | C | R | R |
| Project evaluation and closure document | C | A | R | R | C | C | C | C | C | C |
| Benefit realisation | A | I | C | I | R | I | I | I | I | I |
| [deliverable] |   |   |   |   |   |   |   |   |   |   |

 Check before approval: one A per row; no row without an R; no person with more R entries than their released time allows.

 ## 6. Time commitment and backfill agreement

 Asking people to do project work on top of an unchanged daily job is the most common cause of delay. This table makes the release of time explicit and puts a line manager's name against it.

 | Name | Project role | Home department | Share of time released, by phase | Peak periods needing extra capacity | Backfill arrangement | Line manager confirming | Confirmed on |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Example: [name] | Functional team lead, procurement and inventory | Purchasing | [agree in project, per phase] | Acceptance test, cutover, first period after go-live | Daily order handling moved to [name]; temporary buyer hired for the period [period] | [name], head of procurement | [YYYY-MM-DD] |
| [name] | [role] | [department] | [agree in project] | [periods] | [arrangement] | [name] | [YYYY-MM-DD] |

 Selection criteria used for the core team: knows the business, is open to changing how it works, and is trusted by colleagues to decide on their behalf. After go-live the core team is intended to continue as [the permanent business systems team / other, agree in project].

 ## 7. Focus groups

 A focus group is called for one question, for a limited time, and is dissolved when it has answered.

 | Focus group | Objective | Members | Sponsor in the project | Start | End | Output |
| --- | --- | --- | --- | --- | --- | --- |
| Example: Part numbering | Decide whether parts are renumbered at migration and define the numbering rule | Engineering, purchasing, warehouse, finance: [names] | Functional team lead, inventory | [YYYY-MM-DD] | [YYYY-MM-DD] | Decision paper to the PMs; rule recorded in the Book of Rules |
| [group] | [objective] | [names] | [role] | [YYYY-MM-DD] | [YYYY-MM-DD] | [output] |

 ## 8. Expert users

 Expert users are trained first, which also tests the training material. They run the Operational Readiness Test while the core team only advises, and confirm on behalf of the business that the solution and the training are sufficient. After go-live they are the first contact for colleagues, before the help desk.

 | Name | Site | Process area | Users they support | Trained on | Trains end users (yes/no) | Released time around go-live confirmed by |
| --- | --- | --- | --- | --- | --- | --- |
| Example: [name] | [site] | Warehouse receipt and counting | Warehouse operators, [shift] | [YYYY-MM-DD] | Yes | [line manager] |
| [name] | [site] | [area] | [group] | [YYYY-MM-DD] | [yes/no] | [name] |

 Coverage check: every site, every shift and every in-scope process area has a named expert user and a named deputy.

 ## Approval

 | Name | Role | Date | Signature |
| --- | --- | --- | --- |
| [name] | Executive sponsor (customer) | [YYYY-MM-DD] | ______________________ |
| [name] | Sponsor (supplier) | [YYYY-MM-DD] | ______________________ |
| [name] | Customer project manager | [YYYY-MM-DD] | ______________________ |
| [name] | Supplier project manager | [YYYY-MM-DD] | ______________________ |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/03-project-organisation-and-raci.md)

## Project Scope Statement Template (IDK-02)

Template IDK-02, version 1.0. Phase: Initiate Project.

 ## How to use this template

 
- Write it during Initiate Project, in parallel with the Project Management Plan ([IDK-01](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/01-project-management-plan)). The plan says how the project is run. This document says what it delivers.
- The supplier project manager drafts it from the contract and the sales-phase material. The customer project manager and the process owners correct it until they recognise their business in it.
- Replace every `[bracketed field]`. Delete rows marked `Example:` once you have your own.
- It is done when the steering group has signed it and every in-scope line has an acceptance criterion and an accepting role. A scope line without an acceptance criterion is an argument waiting to happen.
- It is confirmed a second time at the Solution Confirmed gate, after the prototype. Changes in between go through change control ([IDK-07](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/07-change-request-and-change-control-procedure)).

 | Field | Value |
| --- | --- |
| Template ID | IDK-02 |
| Phase | Initiate Project |
| Owner | Supplier project manager (with customer project manager support) |
| Approver | Steering group |
| Qualification gate | Project Initiated |
| Version | 1.0 |

 ## Contents

 
- [Document control](#document-control)
- [1. Purpose and background](#1-purpose-and-background)
- [2. Objectives and measurable benefits](#2-objectives-and-measurable-benefits)
- [3. Software scope](#3-software-scope)
- [4. Solution scope by process area](#4-solution-scope-by-process-area)
- [5. Out of scope](#5-out-of-scope)
- [6. Acceptance criteria](#6-acceptance-criteria)
- [7. Work breakdown and responsibilities](#7-work-breakdown-and-responsibilities)
- [8. Milestones](#8-milestones)
- [9. Constraints and dependencies](#9-constraints-and-dependencies)
- [Approval](#approval)

 ## Document control

 | Version | Date | Author | Change | Approved by |
| --- | --- | --- | --- | --- |
| 0.1 | [YYYY-MM-DD] | [name, role] | First draft from contract and statement of work |   |
| 1.0 | [YYYY-MM-DD] | [name, role] | Baseline for gate Project Initiated | [steering group chair] |
| [n.n] | [YYYY-MM-DD] | [name, role] | Confirmed after prototype, gate Solution Confirmed | [steering group chair] |

 ## 1. Purpose and background

 | Item | Content |
| --- | --- |
| Why the business runs this project | [two or three sentences in business language, not system language] |
| What triggered it now | [for example: legacy system end of support, acquisition, growth constraint] |
| Link to corporate goals | [which goal, and how this project serves it] |
| Contract or statement of work | [reference, date] |
| What this document supersedes | [sales presentations, proposal appendices, earlier scope lists] |

 ## 2. Objectives and measurable benefits

 Each benefit has one owner in the business, a measure, and a date by which it is expected. The executive sponsor is accountable for benefit realisation. Progress is reviewed at each steering group meeting.

 | ID | Objective | Benefit and how it is measured | Baseline today | Target | Expected by | Benefit owner |
| --- | --- | --- | --- | --- | --- | --- |
| Example: B-01 | One purchasing process across all sites | Share of purchase order lines raised from an approved requisition, read from a lobby element on purchase order data | [measure today] | [agree in project] | [YYYY-MM-DD] | Head of procurement |
| Example: B-02 | Trustworthy stock records | Count accuracy by location, from counting results in the system | [measure today] | [agree in project] | [YYYY-MM-DD] | Warehouse manager |
| [ID] | [objective] | [benefit and measure] | [baseline] | [target] | [YYYY-MM-DD] | [role, name] |

 Objectives that are not measurable are listed here as intentions, with no owner commitment:

 
- [intention]

 ## 3. Software scope

 | Item | In scope |
| --- | --- |
| Product and release | IFS Cloud, release [release] at project start |
| Deployment option | [hosted by IFS / remote deployment at customer] |
| Components and modules licensed | [list from contract] |
| Components licensed but not implemented in this project | [list, with reason] |
| User types and counts | [from contract; do not restate figures here, reference the contract clause] |
| Languages | Application: [languages]. Documentation and handover: English plus [language]. |
| Localisations and country extensions | [list] |
| Mobile and device use | [for example: warehouse handhelds, maintenance mobile app] |
| Third-party products in the solution | [product, purpose, who contracts it] |
| Update approach | Service updates and release updates: [cadence agreed in project]; first update after go-live planned for [period] |

 ## 4. Solution scope by process area

 The process model in [IFS Scope Tool or agreed repository] holds the detail. This table is the signed summary. One row per end-to-end process.

 | Process area | End-to-end process | Sites and companies | Process owner (customer) | Standard functionality expected | Known CRIM need |
| --- | --- | --- | --- | --- | --- |
| Example: Procurement | Purchase requisition to supplier invoice match | [sites] | Head of procurement | Yes. Authorisation rules configured per company. | One integration: order data to transport planning through a standard projection |
| Example: Inventory | Receipt, putaway, movement, counting, adjustment | [sites] | Warehouse manager | Yes | One configuration: custom field for internal hazard class on the part record, visible in receipt |
| Example: Security | Roles and permission sets for all in-scope processes | All | Customer IT lead with process owners | Yes. Functional roles built from end-user permission sets, segregation of duties reviewed by finance. | None |
| [area] | [process] | [sites] | [role, name] | [yes / partly / no, with note] | [CRIM reference or none] |

 
### 4.1 Data scope

 | Data set | Source | In scope | History migrated | Method | Customer owner |
| --- | --- | --- | --- | --- | --- |
| Example: Suppliers and supplier addresses | Legacy ERP | Active suppliers only; definition of active: [agree in project] | None | Data Migration Manager | Procurement data steward |
| Example: Inventory balances | Legacy ERP, final count | All in-scope sites | Opening balance only | Data Migration Manager | Warehouse manager |
| [data set] | [source] | [rule] | [depth, agree in project] | [migration tool / copy and paste / manual entry] | [role] |

 
### 4.2 Interface scope

 Every legacy and new interface is listed, including the ones that will be retired. The full interface register is built before the build starts.

 | ID | From | To | Data flowing | Direction | Status in the new solution |
| --- | --- | --- | --- | --- | --- |
| Example: INT-03 | IFS Cloud | Transport planning system | Confirmed purchase order lines, delivery address, wanted receipt date | Outbound | New, replaces file export from legacy |
| [ID] | [system] | [system] | [data] | [in/out/both] | [new / kept / retired] |

 ## 5. Out of scope

 Writing down what is excluded prevents more disputes than writing down what is included. Each line states the reason and where the need goes instead.

 | Item | Reason | Where it is handled instead |
| --- | --- | --- |
| Example: Migration of closed purchase orders | No operational use after go-live; legal retention met by legacy archive | Read-only legacy archive owned by customer IT |
| Example: Organisational change management activities | Customer responsibility | Customer change lead, plan reference [reference] |
| Example: Sites [site list] | Later roll-out | Separate project, not budgeted here |
| [item] | [reason] | [owner or follow-on project] |

 ## 6. Acceptance criteria

 
### 6.1 Acceptance of the product delivery

 The product is what the customer will operate: configured IFS Cloud, CRIM objects, migrated data, roles and permission sets.

 | # | Criterion | How it is proven | Accepting role |
| --- | --- | --- | --- |
| 1 | Every in-scope process meets the agreed requirement | Solution Acceptance Test scripts passed, results logged in the test tracker | Process owners |
| 2 | The solution works with the physical operation | Test steps executed in the real warehouse, shop floor or office setting, with devices and printers | Process owners |
| 3 | The built solution, including CRIM, is complete and has no operation-critical error | Defect list with classification; none open that block deployment | Customer PM |
| 4 | Migrated data is fit for purpose | Functional validation sign-off per data set after the final load iteration | Data owners |
| 5 | Roles match business roles | Test executed with end-user logins and their permission sets, not with administrator access | Customer IT lead and process owners |
| 6 | Step-by-step guides are accurate | Guides followed during acceptance test without consultant correction | Functional leads |
| [n] | [criterion] | [proof] | [role] |

 Defect classes that block acceptance: [definition agreed in project]. Defects that may close after the phase: agreed individually and listed with owner and date.

 
### 6.2 Acceptance of the project delivery

 The project delivery is the work: phases completed, deliverables handed over, people enabled.

 | # | Criterion | How it is proven | Accepting role |
| --- | --- | --- | --- |
| 1 | Each qualification gate passed | Gate decision record signed by the steering group ([IDK-08](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/08-qualification-gate-checklists)) | Steering group |
| 2 | Agreed supplier documents delivered | Document list in [IDK-01](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/01-project-management-plan) section 10 ticked, latest versions in the repository | Customer PM |
| 3 | Core team and expert users can operate and support the solution | Operational Readiness Test completed by expert users, with the core team only advising | Executive sponsor |
| 4 | Handover to support executed | Handover document complete, CRIM specifications and test specifications in latest version, handover meeting held and recorded | Both PMs and support lead |
| 5 | Residual issues owned | Closure document lists each residual issue with owner and date | Steering group |
| [n] | [criterion] | [proof] | [role] |

 ## 7. Work breakdown and responsibilities

 One row per work package. R is the party doing the work, S the party supporting it.

 | Work package | Phase | Main deliverable | Customer | Supplier |
| --- | --- | --- | --- | --- |
| Project initiation and planning | Initiate Project | Approved plan, scope statement, controls | S | R |
| Operating model workshops | Confirm Prototype | Book of Rules documents approved by customer | R (decisions and content) | R (facilitation and documentation) |
| Prototype build and demonstration | Confirm Prototype | Approved prototype on customer sample data | S | R |
| Data cleansing | From Confirm Prototype | Cleansed source data per data set | R | S |
| Data mapping and load iterations | Establish Solution | Validated migration jobs | R (extract, validate) | R (mapping, load support) |
| Solution workshops and configuration | Establish Solution | Configured processes, revised Book of Rules | R (decisions, testing) | R (configuration) |
| Roles and permission sets | Establish Solution | Functional roles built and tested | R | S |
| CRIM specification and build | Establish Solution | Approved specifications, delivered and tested objects | R (approve, test) | R (specify, build, unit test) |
| Step-by-step guides and training material | Establish Solution | Final guides and course material | R | S |
| Solution Acceptance Test | Establish Solution | Documented and approved test result | R | S |
| Expert user and end-user training | Implement Solution | Trained users attached to roles | R | S |
| Operational Readiness Test | Implement Solution | Documented and approved test result | R | S |
| Cutover planning and rehearsal | Implement Solution | Tested cutover plan, checklist and rollback plan | R (business tasks) | R (technical tasks, plan ownership: [agree in project]) |
| Cutover and go-live support | Go Live | Solution in operation | R | R |
| Handover to support and closure | Go Live | Handover document, project evaluation, closure document | S | R |
| [work package] | [phase] | [deliverable] | [R/S] | [R/S] |

 ## 8. Milestones

 Dates are held in the schedule baseline ([IDK-01](https://www.ifs-erp.com/en/marketplace/implementation-docs-kit/01-project-management-plan) section 3). Listed here so that scope and milestones are signed together.

 | Milestone | Phase | Baseline date |
| --- | --- | --- |
| Gate: Project Initiated | Initiate Project | [YYYY-MM-DD] |
| Kick-off held | Confirm Prototype | [YYYY-MM-DD] |
| Prototype approved. Gate: Solution Confirmed | Confirm Prototype | [YYYY-MM-DD] |
| Solution Acceptance Test approved. Gate: Solution Established | Establish Solution | [YYYY-MM-DD] |
| Cutover rehearsal completed | Implement Solution | [YYYY-MM-DD] |
| Operational Readiness Test approved. Gate: Go Live Authorised | Implement Solution | [YYYY-MM-DD] |
| Go-live | Go Live | [YYYY-MM-DD] |
| Gate: Go Live Complete | Go Live | [YYYY-MM-DD] |

 ## 9. Constraints and dependencies

 | Type | Description | Owner |
| --- | --- | --- |
| Example: Dependency | Transport planning system supplier must deliver its side of INT-03 before integration testing | Customer IT lead |
| Example: Constraint | Go-live must fall on a financial period boundary and outside the seasonal peak | Finance director |
| [type] | [description] | [role] |

 ## Approval

 | Name | Role | Date | Signature |
| --- | --- | --- | --- |
| [name] | Executive sponsor (customer) | [YYYY-MM-DD] | ______________________ |
| [name] | Sponsor (supplier) | [YYYY-MM-DD] | ______________________ |
| [name] | Customer project manager | [YYYY-MM-DD] | ______________________ |
| [name] | Supplier project manager | [YYYY-MM-DD] | ______________________ |
| [name] | Process owner, [area] | [YYYY-MM-DD] | ______________________ |

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

 Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.


[Read more...](https://www.ifs-erp.com/implementation-docs-kit/02-project-scope-statement.md)