Emily’s Rebellion: A business guide to designing better transactional services for the digital age

Book Description

Emily is feeling rebellious. Emily - the embodiment of many young business people the authors have worked with on system projects - faces a wall of "you don't understand how complex it is". She is told: "You do not have enough experience to make changes", "Best we keep going with the current work the way it is", and "We will think about improvements later." Emily becomes disillusioned and disempowered.

Emily's Rebellion presents a new method of removing the complexity from business processes and information systems called the 'Transaction Pattern'. Emily has learned about Service Design and loves it, but she needs a way to bridge the gap between her customer-focused service blueprint and the technical-minded developers.

The Transaction Pattern is Emily's bridge. It breaks down a service design into transactions and then into a generic pattern of phases and tasks that commonly recur. This structured approach, based on the pattern, readily specifies business requirements for system development and process implementation.

Emily's Rebellion seeks to embolden people like Emily who are required to inhabit the space between the everyday operations of their business and technology 'improvement' and digitization projects. You can effect change today with simple steps - it does not have to be so complex. Walk with Emily as she discovers a new path to get better business outcomes from IT projects.

Table of Contents

  1. Foreword
  2. Preface
  3. Acknowledgements
  4. PART I: Transaction Foundations
  5. Chapter 1: Introduction
    1. Designing services for the digital age
    2. The customer-facing and internal process journeys are distinct but aligned
    3. The Requirements Black Hole
    4. How Emily’s rebellion can become a revolution
    5. Concept map
    6. Emily’s glossary
  6. Chapter 2: Trading Sheep in Sumer
    1. Transactions create data
    2. Recording nouns
    3. Cuneiform
    4. Data matters
    5. Data is at the heart of a business
    6. Six kinds of data
    7. How to tell master data from transaction data
    8. Launching the payload
    9. Managing transaction data better
    10. Three key points from this chapter
    11. Further reading
  7. Chapter 3: Responding to Requests
    1. People, patterns, and prehistory
    2. Business processes and the transaction pattern
    3. Transactions comprise a request and a response
    4. Transactions exchange value
    5. Transacting requires a decision
    6. Transactions follow a consistent pattern of changing statuses
    7. A generic pattern of request and response
    8. Requests are resilient to changing response processes
    9. Varying the transaction pattern
    10. Three styles of transactional complexity
    11. Three key points from this chapter
  8. Chapter 4: Experience the Service
    1. The Service Design approach
    2. A service blueprint sets the context for transaction design
    3. Identifying transactions
    4. Three key points from this chapter
    5. Further reading
  9. Chapter 5: Grand Designs
    1. Form and function
    2. Why does business need an architecture?
    3. Business architects understand how the business works, and how well
    4. How does architecture help Emily?
    5. Three key points from this chapter
    6. Further reading
  10. PART II: Transaction Methods
  11. Chapter 6: A Job to Do
    1. Getting down to work
    2. Initiate phase
    3. Submit phase
    4. Validating before processing
    5. Validate phase
    6. Decide phase
    7. Complete phase
    8. Like transactions, tasks also have a status
    9. The flow of work tasks through the workplace
    10. The data about transactions and tasks can be generalized
    11. Bringing all these ideas together
    12. Roles people play
    13. Three key points from this chapter
    14. Further reading
  12. Chapter 7: A Task Shared is a Task Halved
    1. What tasks can be shared across transactions?
    2. Arrange the pattern diagram differently
    3. Shared tasks interlock with transaction-specific tasks
    4. Specification of requirements for shared tasks
    5. Identification
    6. Notification tasks
    7. Payment
    8. Approval
    9. Future activity scheduling
    10. Customer interactions
    11. Three key points from this chapter
  13. Chapter 8: Interacting with Customers
    1. Interactions move transactions forward
    2. Categories of interactions
    3. Channels for interacting
    4. Data about interactions
    5. Verbal interactions
    6. Informal written interactions
    7. Formal written interactions
    8. Why is this important?
    9. Three key points from this chapter
  14. Chapter 9: Do we know what we want?
    1. A framework for discussing requirements
    2. Getting the workshop underway
    3. Overview of the transaction
    4. Stepping through the five phases
    5. Wrapping up the workshop
    6. Documenting your workshop outputs in a transaction requirements document
    7. Reviewing and approving a transaction requirements document
    8. How is the transaction requirements document used?
    9. Three key points from this chapter
  15. PART III: Implementing Transactions
  16. Chapter 10: Fomenting Revolution
    1. Managing change
    2. Managing the change of adopting the Transaction Pattern
    3. Transaction Pattern techniques
    4. Steps to implementing the Transaction Pattern
    5. Three key points from this chapter
    6. Further reading
  17. Chapter 11: Putting the Pattern into Practice
    1. The case study scenario
    2. The value stream
    3. The customer journey
    4. The business objects and data
    5. Narrowing the focus to one transaction
    6. The business objects involved in the submit claim transaction
    7. The insurance claim business process
    8. Align the process to the Transaction Pattern
    9. Eliminate unnecessary business tasks
    10. Holding a requirements workshop
    11. Creating the transaction requirements document
    12. Improving the transaction requirements document
    13. Communicating the transaction requirements document
    14. Three key points from this chapter
  18. Chapter 12: Emily’s Triumph
    1. A wide range of benefits
    2. Benefits in the internal process domain
    3. Benefits in the data domain
    4. Benefits in the customer experience domain
    5. Benefits in the harmonization domain
    6. The direct benefits ultimately contribute to strategic outcomes
    7. Three key points from this chapter
    8. Further reading
  19. Index

Product Information

  • Title: Emily’s Rebellion: A business guide to designing better transactional services for the digital age
  • Author(s): Lloyd Robinson, Graham Wilson
  • Release date: January 2019
  • Publisher(s): Technics Publications
  • ISBN: None