One of the most common reasons for not working together is…
“But, we do something different!”
To some degree this is true.
Within the context of social housing, whilst each organisation provides the same set of core services, how those services are delivered, and by what technological means results in an impressive number of possible variations.
My perception is that this also applies across other sectors like health and local government. The lack of commonality or shared undersanding between these organisations and sectors makes collaboration, even with concerted effort and good will, really hard.
What if we zoomed out a bit?
What if we pushed back from the specifics just enough to reach a shared abstract understanding of how things work?
Two ways we might do this…
Data Standards
Abstracted from specific systems or services, a common recognised set of open data standards that help define what things are.
When we collect Marital status for someone, how do we store it? How many statuses do we have? Is it stored as a code? What do the codes mean?
Often, how we store data is mandated by the technology choices we make during procurement of IT systems. What if we applied a standard to all the systems we use so that our data is agnostic of our technology choices?
In social housing we have something called the UK Housing Data Standard. It is rapidly maturing through use across not just Housing Associations but also Councils. It helps us rationalise how we store stuff. It also helps us communicate data with others in a clear and consistent way.
Service Patterns
The way we deliver services could be thought of as a collection of processes that may be distributed across one or more team or departments.
These processes often come to be defined or constrained by the capabilities of the technology they are implemented upon.
In turn that means that similar organisations often end up with bespoke ways to deliver the same service due to different technology choices.
What if we had a way of describing our services in a more abstract manner?
Abstract enough that if we deliver the same service in different organisations, that I can recognise the pattern without having to understand the specifics.
Or as a housing person, what if I could see an abstract of a service in health without having to first parse sector specific acronyms and terminology? This may help me understand that some of the ways we register a user or book appointments is actually very similar.
Enter service patterns.
We think that for a service pattern to be useful it has to be a way of documenting or sharing a common user experience or user journey, and, as importantly, a supporting business process.
This is a quote from Ben Holliday of FutureGov (see original post here).
FutureGov have a project to build an open National pattern library to foster an element of consistency, knowledge sharing and reuse across all local government organisations.
By breaking down services into their component parts, we can start to identify common interactions and tasks across stages of services – things like reporting a problem, applying for something or checking eligibility.
See an example below around ‘reporting a repair’.
Service patterns are not detailed enough to tell the whole story of how something works because there’s a moderate level of abstraction, but it’s just enough detail to recognise that people in different organisations might be doing very similar things that benefit from further joined up thinking.
*A final caveat
This is probably wrong, and part of writing down here is figuring out specifically how it’s wrong. Your help in making it less wrong is always appreciated. 🙏 Leave a comment here or ping me @NeilTamplin on Twitter.