A business guide to designing better transactional services for the digital age
Computers are the most stupid things on earth. Humans can make a mess, but it takes a computer to take it to mind-numbing, brain exploding, star destroyer levels. So when we take business processes (and data) from manual to more automated (or semi-automated to fully automated) systems, we must simplify the process. Humans are flexible and will identify many common process errors, correcting them before they appear in a business process exception queue.
It is incredibly difficult to put even simple business transactions into digital platforms in a robust and resilient way. Mapping the customer’s experience and designing a better experience are easy enough. The hard part is what lies behind the experience facade, out of sight of the customer.
Most projects do not take a gradual approach to delivery of an evolving footprint. They try to do too much, too complicated. Emily’s way is to break down a transaction into a series of tasks, which are simpler to specify and implement.
Western Civilisation is a clash between Tortoises and Hares. Of course, one particular Tortoise first wrote the story down to claim victory, but Hares continue to flourish and operate. Hares never get around to writing their version of the story – too busy rushing around. Let’s implement a strategy in two months. Let’s revolutionise the business in a year. No, let’s slowly work through this problem, improving the business each month. Boring, steady and unimpressive. Such is human progress based upon.
This book is written by Tortoises, not Hares. It is written for other Tortoises out there who can see human progress over their lifetime and want to brush aside the daily news cycle to move the universe forward.
In the 1980s, we had huge wars over process and data perspectives in system requirements and design. However, recently, processes and customer experience have become the flavour of the millennium. The authors have reviewed many business requirements with no regard to data and how the data will evolve through the customer journey. The inescapable truth is that transactions with customers create data, which becomes a valuable asset for the business.
When we take a data perspective of an organisation, we see a different world. We see a world where processes execute to push the state of data forward, but the only present reality is data. If we turned off our computers and human processes, the data would still be waiting for us to return to move it along.
When humans started writing, for the first 5,000 years there were no verbs, just nouns. Writing on clay tablets was very expensive and only the most important parts could be afforded (nouns and quantities). The earliest writing recorded transactions, not prose. 12,000 years later, modern smart phones have taken off to be ubiquitous across the planet. When you look at the interface, there are few verbs, mostly nouns (in states). The operator uses the screen to process the data to a different state, such as creating a new contact. People do the process on the nouns. This is why they are so easy to understand, they are natural to our brains (the first big data machines and intelligence).
System developments and process redesign projects often fail to meet expectations. Frequently this is due to poorly understood and badly specified business requirements. The language used in requirements needs to controlled, so that a term used here means the same thing over there. The requirements for one transactional service need to be separated from those of another transaction. This makes communicating requirements far easier, ensuring a less-antagonistic relationship with developers.
With well-understood language, Emily discusses and specifies the business requirements for each transaction using a standard pattern that streamlines the effort. At the same time the requirements retain the intent of the desired customer experience, within an overarching architecture that delivers the business strategy. Emily’s approach avoids losing these perspectives, like building a bridge with only construction workers and no architects or engineers and wondering why it takes forever and fails to improve traffic flow.
The greatest difficulty humans have in working together is language. Language creates silos of data and the processes that operate on them become isolated (since the data is different the processes cannot be combined). Emily first starts to align language across her processes, to make it easier to understand how her operations teams are going.
She makes order of magnitude simplifications to processes, statuses and data. Then she can see across the whole enterprise, not just one of the silos. She saves on all that automation complexity, because, frankly there is less to automate.
Emily seeks to properly engineer her transactional services, simplifying and standardising on the way, and then to automate the new way of working. With processes moving through a common sequence of statuses, operational management reporting becomes so much simpler, easing a lot of the pain involved in managing a large operation.
Firstly, you need to realise that business and data engineering is not an IT exercise. It does not need developers, packages, testers or IT project managers. They deliver solutions to problems. The real question is “what is your problem”.
Construction people can never help with defining your problem. It is like asking your plumber whether they think you need a new bathroom. Or your solicitor if you should get divorced.
Not realising the importance of problem and outcome definition is a critical failure. Business people need to assess and diagnose their problem before engaging solution people. This results in many projects becoming “headless chicken races”. There is a fantastic amount of activity, often all week and into the weekend, but the solution is a dead mess. Emily’s Rebellion offers business people access to a set of tools to take control of IT projects, and to get solutions that align with their problem and their vision for transacting better with customers.
The book focuses Emily on a clear set of steps and outcomes she can execute and measure her success on and engage the solution delivery teams in a coordinated and helpful way.