Marketplace

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.
Template metadata
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

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) Customer project manager
R: Report Quick reports, operational report layouts, analysis models and other outputs beyond standard Configuration and report specification (template IDK-12) 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) Functional specification (template IDK-11) 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) 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.