How business process mapping saved an IT project.

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

10 comments

Comments 1 - 10 of 10 previous next Post a comment

  • vshah011 vshah011 1 month ago
    Great presentation! Can you please send a copy to vshah@blueyonder.co.uk, thanks
  • remysam remysam 1 month ago
    Great work!! I would appreciate if you can me a copy @ remysam@gmail.com
  • dbreuer dbreuer 1 month ago
    Great job. I wuold appreciate a copy sent to me at dave_breuer@cuone.org
  • mosheaapts mosheaapts 3 months ago
    I have been working to get our organization to embrace a business process apporach and this would serve as good part of that case. The laguage here is spot on for my audience. Can you send me a copy at moshea@apartments.com please?
  • guest90ee56 guest90ee56 4 months ago
    Good presentation. I would appreciate it if you could mail me a copy (dvperren@worldonline.be).
    Thanks in advance.
  • guest249d8a guest249d8a 4 months ago
    excellent presentation, would you please share to me dhakane@gmail.com
  • Alexander.Polyanskiy Alexander.Polyanskiy 4 months ago
    Very nice presentation. The example is 100% comparable to the real life example from my experience. I'd appreciate for the sent copy to alexander.polyanskiy@gmail.com

    Many thanks in advance,
    Alexander
  • guestc03804a guestc03804a 4 months ago
    This is a fantastic and yet simple to understand presentation. Kindly mail me a copy: osynon@yahoo.com
  • guestf1d87b2 guestf1d87b2 4 months ago
    excellent presentation, would you please share to me @ rhaitham@yahoo.com

    thanks,
  • highwayman highwayman 5 months ago
    kindly mail copy to sadana@in.com
Post a comment
Embed Video
Edit your comment Cancel

Notes on slide 1

Corp com does not want to share information about our internal business practices. - Did not like verbiage “good enough” in presentation. - Cannot use movie images of any kind

63 Favorites & 1 Group

How business process mapping saved an IT project. - Presentation Transcript

  1. Case Study: How Business Process Mapping Saved an IT Project Garrett Hunter Director, Information Technology Sony Pictures Entertainment [email_address]
  2. Case Study Summary
    • Explore how combining business process mapping techniques with use case development helped to successfully deliver an IT project
    • Review how industry bodies of knowledge such as the Business Process Model Notation specification and the APQC Process Framework were leveraged to provide a common business process vocabulary for both the IT team and the business customers
  3. Case Study Key Issues
    • Explaining what a workflow is to business
    • Translating workflows into system requirements
    • Helping our business customers agree on the process
    • Why "Good Enough" is OK
  4. Project Background
    • The “Automated System for Ad/Pub Fulfillment” was to manage the fulfillment of marketing materials for all international offices & agents
    • Marketing materials
      • T-Shirts
      • Keychains
      • One Sheets
      • And anything else a marketer can imagine
  5. Project Background – Scope
    • Primary stakeholders were interviewed to determine system features
      • Online shopping Cart
      • Product Master
      • Receiving
      • Inventory Management
    • Additional interviews were conducted with users to generate use cases for system configuration and customization
    • The new system would be replacing processes executed with spreadsheets, email, and paper
      • Manually intensive processes
  6. Project Background – Delivery Methodology
    • Scope and features were defined in an unstructured narrative style
      • High level business modeling included via flowcharts
    • Use cases were used to define development requirements
      • A use case documents the step by step actions a user performs to complete a specific activity
    • Majority of rigor placed upon developers to produce class diagrams and data models
  7. Project Background – Primary Deliverables Use Cases Diagrams Narrative Flow Charts
  8. Missed Requirements
    • After several months of analysis and development, the first release date was missed because the customer would not sign off on the system implying IT does not understand our business
    • Further analysis revealed multiple requirements that were missed because business rules were not explored in depth
      • Process for assigning order fulfillment was more complicated than initially thought
      • The number & complexity of business rules was underestimated
  9. Short Term Corrective Steps
    • Focused on modeling the end-to-end business processes to better understand what we were missing
    • Conducted Bi-weekly meetings with customer to map their processes
      • Helped to both rebuild credibility & capture an accurate understanding of all business rules
      • Required the project to determine how much was “enough” detail to capture
    • Started the process for defining a long term solution to ensure we would do better at understanding the business problem
  10. Process Mapping Success
    • Able to describe the exact steps our customer performed as part of their work
      • This allowed us to better empathize with their current challenges and demonstrate our intent to deliver a usable system
    • Able to call out specific areas within the application that needed customization and which steps would be automated
    • Customer VP personally expressed his gratitude that “IT finally understands what we have to go through”
  11. Tips for Ensuring Success
    • Get them all in the same room / on the same call
    • Focus on the person actually performing the work
      • Not their supervisor / boss
    • Get agreement on the start and end points of the process
      • Helps to set the scope of the process mapping
    • Get agreement on the inputs & outputs
      • Critical to finding all handoff points and involved parties
    • Be transparent, show them your models
  12. Long Term Corrective Steps
    • Create guidelines on how to link business processes to system requirements
      • Traceability is a powerful control to ensure the team is delivering what the customer expects
    • Develop business modeling as a discipline and not a byproduct
      • Traditionally, we emphasized delivering coding requirements & not process requirements
    • Expand Our business modeling to include the entire business process, end-to-end, and not just discrete steps along the way
      • Focus on automation objectives rather than coding requirements
  13. Creating a set of Guidelines
    • Projects were using numerous tools and diagramming techniques to document business process models
      • Quality of deliverables too dependent on the whims of the analyst
    • Needed an approach that would appeal to the widest audience
    • Needed something that was widely understood outside of The Company
    • It needed to be compatible with our current development methodology based on use cases
  14. Diagramming Candidates
    • The Business Process Modeling Notation (BPMN) specification
      • Sponsored by the Object Management Group, it offered a way to standardize our diagrams
      • Notation similar to our existing use of swim lane / workflow diagrams
    • Unified Modeling Language (UML)
      • The standard in object oriented development it offered a number of related models for developing requirements
      • Activity diagrams closest to what we would need
  15. A Best-of-Breed Solution
    • BPMN offered the best combination of flexibility and standardization to link process models to software design
      • Standardized diagram symbols
      • Required the “who” in each diagram
      • Easily understood by non-techies (for the most part)
      • Already had BPM systems in house using the notation
    • UML proved to be too focused on software development and required more training to educate the end consumer
    • We would add additional notations such as inputs & outputs
      • Borrowed from IDEF0
  16. A Best-of-Breed Solution
    • Use cases would be derived from specific process steps and continue to form the basis for system requirements
    • Data models would be driven by inputs & outputs from the process diagrams
    • We would create a process modeling style guide that would connect all the pieces together
  17. BPMN from the Start
    • Project analysis would begin with a Level 1 process diagram using the BPMN 1.x specification
      • Short list of core graphical elements meant a short learning curve
      • Just the core set of elements for our initial release were used
  18. Business Modeling as a Discipline
    • Using BPMN we started at a macro level and methodically decomposed any step in the process that was unclear
    • Divided into three levels, increasing in detail
      • Level 1 = Handoff Level
      • Level 2 = Milestone Level
      • Level 3 = Logic / Task Level
    • We took our guidance from the book Workflow Modeling: Tools for Process Improvement and Application Development (A. Sharp, P. McDermott, Artech House, Inc. 2001)
    • This rigor enabled the team to document the processes without becoming lost in unnecessary details
  19. Level 1 – Handoffs
    • Map enough of the processes to understand what we missed
      • Keeps us focused on what happens
    • Start at a level where you can focus strictly on the handoffs between people participating in the process
    1 Organize daily service order fulfillment schedule Explored in Level 2
  20. Level 2 – Milestones
    • Next we selected a process step & focused on documenting milestones within that step
      • Illustrates decisions that affect the flow in a significant way
    • The process shown here is derived from a single step
    1.1 Create Distribution List Explored in Level 3
  21. Level 3 – Logic / Tasks
    • Depending on complexity we would further break down each step to get to the how
      • This is the first time we get to the procedural level
    • This level of modeling maps closely to the steps within a use case
    • Naming convention tells the reader this was derived from a higher level model
    1.1.1 Create Shipping List from Premium Orders
  22. Process Step Naming Conventions
    • Avoid using ambiguous terms such as process or manage
      • The diagram being created is the process
    • Always use a verb – noun combination
      • Create distribution list
      • Pick order
      • Pack order
    • Use only one verb at a time
      • Using multiple verbs can hide your meaning an complicate the diagram
  23. Connecting to System Requirements
    • Our process diagrams became the agreement (aka requirements) between project and our customer
      • Each step in the process diagram had the potential to be a use case
    • Use cases continued to be the requirements between business analyst & developer
    • Use case packages (in keeping with UML) were driven by how we organized our process models
  24. A Style Guide to Bind Them All
    • To be truly successful this needed to be a sustainable process
    • Tool agnostic process modeling style guide developed to reduce complexity by limiting which elements from the BPMN spec would be used
      • Our team lacked experience modeling processes and needed guidance before descending into analysis paralysis
    • Topics covered include
      • Acceptable graphical elements
      • Diagram naming conventions
      • Process step naming conventions
  25. Traceability
    • USE CASE
    • Basic Flow
    • Do this
    • Do that
    • Stop here
    Data Models Process Models
  26. Explaining Our Approach to the Customer
    • Never used technical terms such as BPMN, use case, or activity diagram
    • Interchangeably called our BPMN diagrams “process maps”, “workflow diagrams”, and “process models”
    • Explained the diagrams as step-by-step pictures of who in their organization does what
    • Kept the diagrams as uncluttered as possible to keep the discussions focused on the work being performed
  27. Business Process As Release Driver 10/22 11/26 11/19 11/12 11/5 10/29 10/15 10/8 10/1 10/22 11/26 11/19 11/12 11/5 10/29 10/15 10/8 10/1 Release 1.4.0 (Clients) Release 1.5.0 (Work Orders) Release 1.6.0 (Pick / Pack & Logistics)
  28. When is “Good Enough” OK?
    • Good enough is OK when…
      • Lives are not at risk
      • Financial statement accuracy is not at risk
      • Business processes are vaguely defined
      • The business is undergoing radical change
    • The very act of implementing a new system and automating numerous manual processes would change the business in ways we could not predict
      • Better to release early and often if possible
  29. Organize and Baseline the Models
    • We used the APQC Process Classification Framework to organize our business processes
    • The taxonomy provided us a structure to catalog each process such that we could baseline them against other business units within The Company
      • For example, the distribution of DVDs in our Home Entertainment division
    © 2006 APQC (www.apqc.org)
  30. After Applying the APQC PCF
    • 4.0 Deliver Products and Services
      • 4.4 Deliver Product Service to Customer
        • 4.4.3 Provide the service to specific customers
          • 4.4.3.1 Organize daily service order fulfillment (Level 1)
          • 4.4.3.1.1 Create Distribution List (Level 2)
          • 4.4.3.1.1.1 Create Shipping List from Premium Orders (Level 3)
    • Notice the concept of levels is subjective
      • This challenge never goes away
      • Always important to pick your perspective and be consistent
  31. Benefits of a Classification System
    • Standardizing process names enables us to compare processes across the enterprise
    • Enables us to see repeating patterns across business divisions
    • Helps to normalize technology portfolios by consolidating systems when possible
    • Allows us to compare ourselves to external organizations
  32. References
    • Sharp, A. & McDermott, P. Workflow Modeling: Tools for Process Improvement and Application Development , Artech House, Inc. 2001
    • BPMN 1.0 , BPMI.org, 2004, Object Management Group, 2006, ( www.bpmn.org )
    • Rational Unified Process , IBM, 2006 ( www.ibm.com/rational )
    • National Institute of Standards and Technology, Integration Definition For Function Modeling (IDEF0) , NIST FIPSP183, 1993 ( http://www.itl.nist.gov/fipspubs/idef02.doc )
    • APQC, APQC Process Classification Framework v4.0.0 , APQC, 2006 ( www.apqc.org )

Garrett HunterGarrett Hunter, 2 years ago

custom

15297 views, 63 favs, 12 embeds more stats

How do we help a project in jeopardy of delivering more

More Info

© All Rights Reserved

Go to text version
  • Total Views 15297
    • 15162 on SlideShare
    • 135 from embeds
  • Comments 10
  • Favorites 63
  • Downloads 954
Most viewed embeds
  • 105 views on http://notesonbpm.sarbashrestha.com
  • 9 views on http://jisi.dreamblog.jp
  • 5 views on http://apolloit
  • 4 views on http://www.mbaclubindia.com
  • 4 views on http://managementulproiectelor.com

more

All embeds
  • 105 views on http://notesonbpm.sarbashrestha.com
  • 9 views on http://jisi.dreamblog.jp
  • 5 views on http://apolloit
  • 4 views on http://www.mbaclubindia.com
  • 4 views on http://managementulproiectelor.com
  • 2 views on http://agriculturalrobotics.com
  • 1 views on http://biologicalcomputers.net
  • 1 views on http://automaticwarehouse.com
  • 1 views on http://www.birminghamstartup.com
  • 1 views on http://www.bpm-research.com
  • 1 views on http://lamevaclasse.blogspot.com
  • 1 views on http://brentwoodtnrealestate.org

less

Flagged as inappropriate Flag as inappropriate
Flag as innappropriate

Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

Cancel

Categories

Groups / Events