Table 2 Steps of the current ITDM... | Emerald Publishing

Table 2

Steps of the current ITDM approach undertaken in the process of car insurance claims

Step	Description	Role
1. Identify problem	Starting Condition: Problems are identified on a regular basis in team meetings due to new requirements or improvement activities During this discussion, the actors ask other users about previous experience with these topics and decide to create a short description about the problem and – if required – collect additional information (i.e. process descriptions, feedback from other departments). In our example, new data quality in the product (the deductible agreements as insurance clauses) leads to improvements in the claims process. This issue was discussed with IT architecture, who identified an optimization potential Output: Problem is a potential demand for a process change	Key User, Expert, PCA (architecture), IT Manager
2. Describe demand	Starting Condition: Process improvement potential is identified Business department describes the as-is scenario. The demand description consists of the to-be scenario in form of a user story: In case of an accident claim, deductibles agreed with cooperating repair shops should be granted automatically. The policy system determines the deductible amount based on agreements with the repair shop. During claims handling, this amount has to be deducted from a payment. In an additional step, the demand creator describes and scores the business case Output: Problem is identified as new demand	Key User, Expert
3. Verify demand	Starting Condition: “description completed”, demand ready for validation by demand and portfolio management The content is checked for completeness by the demand manager. Team architecture raised concerns about interfaces to one external provider. The responsible IT manager checked if the initial budget for an estimation is available. Technical and business analysts estimated the demand. During the estimation, a technical and business concept was created and jointly approved by IT and business department. Due to missing information on how the deductible was originally considered, the concept included only a to-be scenario. After the concept and the estimation is accepted, the demand is officially ordered Output: Demand approved, Budget for effort estimation released	Demand Manager, IT manager, PCA (architecture), Portfolio Manager
4. Realize demand	Starting Condition: Demand commissioned, and the tasks are planned in the backlog Description: Implementation of the demand according to the specification and concept, the development team faced problems due to unexpected interface, the specification to the policy agreements were unclear. The technical communication to the external provider was complicated because of a wrong service definition. Due to an incomplete test case description, the tests of the new functionality did not consider a full end-to-end scenario Output: Demand implemented and tested, transported to production	IT Expert, IT Manager
5. Finalize demand	Starting Condition: Demand implemented/accepted Demand is accepted in production system and the new functionality is subject to a previously agreed stabilization period. Due to problems in the development the budget exceeded the estimations by 50%. Although business department accepted the demand in user acceptance test (UAT), there have been problems in production due to missing conceptual work in the process. Dependencies to other demands were not clarified (an open concept from the agreement specifications in the policy system were different to the specified steps in claims) Output: Demand finalized. Software delivery accepted in production	IT Manager, Key User, Expert
6. Invoice demand	Starting Condition: Demand Finalized Demand is closed in the systems, bookings are no longer possible, the expenses are invoiced to the client Output: Billing to customer Demand closed	IT Manager, Portfolio Manager
7. Maintain demand	Starting Condition: Demand Invoiced If agreed in the demand, the new functionality can be subject to regular reporting Output: Reporting on regular basis	Operations, Demand Manager, BPM

Step	Description	Role
1. Identify problem	Starting Condition: Problems are identified on a regular basis in team meetings due to new requirements or improvement activitiesDuring this discussion, the actors ask other users about previous experience with these topics and decide to create a short description about the problem and – if required – collect additional information (i.e. process descriptions, feedback from other departments). In our example, new data quality in the product (the deductible agreements as insurance clauses) leads to improvements in the claims process. This issue was discussed with IT architecture, who identified an optimization potentialOutput: Problem is a potential demand for a process change	Key User, Expert, PCA (architecture), IT Manager
2. Describe demand	Starting Condition: Process improvement potential is identifiedBusiness department describes the as-is scenario. The demand description consists of the to-be scenario in form of a user story: In case of an accident claim, deductibles agreed with cooperating repair shops should be granted automatically. The policy system determines the deductible amount based on agreements with the repair shop. During claims handling, this amount has to be deducted from a payment. In an additional step, the demand creator describes and scores the business caseOutput: Problem is identified as new demand	Key User, Expert
3. Verify demand	Starting Condition: “description completed”, demand ready for validation by demand and portfolio managementThe content is checked for completeness by the demand manager. Team architecture raised concerns about interfaces to one external provider. The responsible IT manager checked if the initial budget for an estimation is available. Technical and business analysts estimated the demand. During the estimation, a technical and business concept was created and jointly approved by IT and business department. Due to missing information on how the deductible was originally considered, the concept included only a to-be scenario. After the concept and the estimation is accepted, the demand is officially orderedOutput: Demand approved, Budget for effort estimation released	Demand Manager, IT manager, PCA (architecture), Portfolio Manager
4. Realize demand	Starting Condition: Demand commissioned, and the tasks are planned in the backlogDescription: Implementation of the demand according to the specification and concept, the development team faced problems due to unexpected interface, the specification to the policy agreements were unclear. The technical communication to the external provider was complicated because of a wrong service definition. Due to an incomplete test case description, the tests of the new functionality did not consider a full end-to-end scenarioOutput: Demand implemented and tested, transported to production	IT Expert, IT Manager
5. Finalize demand	Starting Condition: Demand implemented/acceptedDemand is accepted in production system and the new functionality is subject to a previously agreed stabilization period. Due to problems in the development the budget exceeded the estimations by 50%. Although business department accepted the demand in user acceptance test (UAT), there have been problems in production due to missing conceptual work in the process. Dependencies to other demands were not clarified (an open concept from the agreement specifications in the policy system were different to the specified steps in claims)Output: Demand finalized. Software delivery accepted in production	IT Manager, Key User, Expert
6. Invoice demand	Starting Condition: Demand FinalizedDemand is closed in the systems, bookings are no longer possible, the expenses are invoiced to the clientOutput: Billing to customer Demand closed	IT Manager, Portfolio Manager
7. Maintain demand	Starting Condition: Demand InvoicedIf agreed in the demand, the new functionality can be subject to regular reportingOutput: Reporting on regular basis	Operations, Demand Manager, BPM

Source(s): Created by authors