2. Blueprint Document

3. 3 About Myself  Was a mainframe developer for 14 years before I transitioned to Remedy development.  My colleagues will tell you I’m old. They’re just jealous because they’ve never read a core dump in hexadecimal.  I’ve been with Kinetic Data for 12.5 years.  My role is solution architecture and technical lead for our professional services group.

4. 4 Overview  Discuss challenges of defining service request requirements.  Benefits of documenting your services.  Benefits of using consistent documentation.

5. 5 Challenges of Defining Service Request Requirements  Not gathering all of the requirements needed before development begins.  Inconsistent requirements documentation causes confusion for service request developers.  Lack of any or accurate documentation creates challenges down the road.

6. 6 The Solution  Gathering all service request requirements before development begins will save you time, money and frustration.  Process owners or subject matter experts fill in the Blueprint Document.  Any Kinetic Request developer will be able to pick up the Blueprint Document and develop the service request.  Support of the service request is easier because you don’t have to be the subject matter expert to understand what’s going on.

7. 7 Blueprint Document Background  Created by a client who started with a document provided by Kinetic Data and expanded on it to meet their needs.  One Blueprint Document for each service request.  Blueprint Document is an Excel Spreadsheet that contains multiple books to organize the various types of requirements.  Taylor this document to meet your needs.

8. 8 Screen Capture General Info

9. 9 Screen Capture Service Process

10. 10 Screen Capture Service Request Questions

11. 11 Screen Capture Remedy Integrations

12. 12 Screen Capture Approvals

13. 13 Screen Capture External Integrations

14. 14 Screen Capture Assignment Groups

15. 15 Screen Capture Notifications

16. 16 Screen Capture Reporting Requirements

17. 17 Screen Capture Service to Service Integrations

18. 18 Conclusion  Consistent and thorough documentation  Speeds development which saves money  You don’t need to be the subject matter expert to develop the service request  New developers don’t need to reinvent the wheel  Increases accuracy (develop the service request correctly the first time)  Provides for better support of the service request as time passes

19. 19 Kinetic Data Delivery Model  Series of documents to aid in service catalog project delivery  Project Kick Off Presentation  Project Plan  Functional Specification (as one document or separated by topic)  Used by Kinetic Data professional services  Provides guidance for requirements gathering and best practices http://www.kineticdata.com/Products/KineticRequest/DeliveryModel.html

20. Questions/Customer Stories