Emily’s Rebellion
Emily’s Rebellion: A business guide to designing better transactional services for the digital age, by Lloyd Robinson and Graham Wilson
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.
Topics
PART I: Transaction Foundations
Chapter 1: Introduction
Designing services for the digital age
Customer-facing and internal journeys distinct but aligned
The Requirements Black Hole
How Emily’s rebellion can become a revolution
Concept map
Emily’s glossary
Chapter 2: Trading Sheep in Sumer
Transactions create data
Recording nouns
Cuneiform
Data matters
Data is at the heart of a business
Six kinds of data
How to tell master data from transaction data
Launching the payload
Managing transaction data better
Three key points from this chapter
Further reading
Chapter 3: Responding to Requests
People, patterns, and prehistory
Business processes and the transaction pattern
Transactions comprise a request and a response
Transactions exchange value
Transacting requires a decision
Transactions follow a pattern of changing statuses
A generic pattern of request and response
Requests are resilient to changing response processes
Varying the transaction pattern
Three styles of transactional complexity
Three key points from this chapter
Chapter 4: Experience the Service
The Service Design approach
A service blueprint sets the context for transaction design
Identifying transactions
Three key points from this chapter
Further reading
Chapter 5: Grand Designs
Form and function
Why does business need an architecture?
Business architects understand how the business works
How does architecture help Emily?
Three key points from this chapter
Further reading
PART II: Transaction Methods
Chapter 6: A Job to Do
Getting down to work
Initiate phase
Submit phase
Validating before processing
Validate phase
Decide phase
Complete phase
Like transactions, tasks also have a status
The flow of work tasks through the workplace
The data about transactions and tasks can be generalized
Bringing all these ideas together
Roles people play
Three key points from this chapter
Further reading
Chapter 7: A Task Shared is a Task Halved
What tasks can be shared across transactions?
Arrange the pattern diagram differently
Shared tasks interlock with transaction-specific tasks
Specification of requirements for shared tasks
Identification
Notification tasks
Payment
Approval
Future activity scheduling
Customer interactions
Three key points from this chapter
Chapter 8: Interacting with Customers
Interactions move transactions forward
Categories of interactions
Channels for interacting
Data about interactions
Verbal interactions
Informal written interactions
Formal written interactions
Why is this important?
Three key points from this chapter
Chapter 9: Do we know what we want?
A framework for discussing requirements
Getting the workshop underway
Overview of the transaction
Stepping through the five phases
Wrapping up the workshop
Documenting your workshop outputs
Reviewing a transaction requirements document
How is the transaction requirements document used?
Three key points from this chapter
PART III: Implementing Transactions
Chapter 10: Fomenting Revolution
Managing change
Managing the change of adopting the Transaction Pattern
Transaction Pattern techniques
Steps to implementing the Transaction Pattern
Three key points from this chapter
Further reading
Chapter 11: Putting the Pattern into Practice
The case study scenario
The value stream
The customer journey
The business objects and data
Narrowing the focus to one transaction
The business objects in the submit claim transaction
The insurance claim business process
Align the process to the Transaction Pattern
Eliminate unnecessary business tasks
Holding a requirements workshop
Creating the transaction requirements document
Improving the transaction requirements document
Communicating the transaction requirements document
Three key points from this chapter
Chapter 12: Emily’s Triumph
A wide range of benefits
Benefits in the internal process domain
Benefits in the data domain
Benefits in the customer experience domain
Benefits in the harmonization domain
The benefits ultimately contribute to strategic outcomes
Three key points from this chapter
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.
Visit the book’s website | DMZ Asia Pac book launch | Author discussion
About Lloyd and Graham
Lloyd Robinson and Graham Wilson have brought their rebellious approach to several major business system initiatives. Lloyd developed the Transaction Pattern over the last 20 years since specifying customer billing systems in the US, and Graham has helped Lloyd to refine the approach in large government projects in Australia. Lloyd is a recognized authority on data management. Lloyd regularly consults and trains in data strategy and management across Australia. Lloyd is widely recognized as an engaging international conference speaker and a contributor to the practical development of the data management profession.
Graham is a business architect with 30 years’ experience in Australian and New Zealand government agencies. Skilled at steering a path between business and IT, Graham has been responsible for guiding business representatives on the architecture of significant government initiatives.
Bestsellers
Faculty may request complimentary digital desk copies
Please complete all fields.