( Zulfikar Deen on “Expectations of owners and users”. The video is at the end of this blog)
Let’s start from an end user. For end-users the solution makes their job easier, more productive and efficient. Any solution which gets delivered to them, they expect them to work hundred percent, there is no full thought process of DevOps and my side of the view here. I can’t have half-baked or DevOps. I got something working for you , let me know how it works, then I will build it better for you, these half -baked doesn’t work for me. When the solution goes to my end user, it has to be working hundred percent. If there are 10 features that have been planned and if three of them are working, then all the three features must work hundred percent. That’s an expectation.
Secondly, the end users are expecting and treating the whole solution as a black box, they don’t differentiate whether it’s an application, it’s a front end, it is a network or it is a backup. If it doesn’t work, it’s of no use. We need to ensure that the whole solution looks at everything and one can’t have a siloed view that it’s my solution. For example if we are rolling out a partner solution to our end user or to an internal built solution, if it doesn’t work then even if the reason is not related to the application the users would still say this application did not work. It’s the responsibility of the whole system to ensure that this whole thing is tested properly and taken a holistic view.
As an IT organizationor or as a CIO organization when the partners are dealing with us, they cannot treat IT organization as their customer because we are not their customers. We and the partner together are servicing our business so they need to co-ordinate and work very well with us to meet the expectations of my business users. Often they make a mistake treating IT organization as a customer. We are not their customers. We are working on behalf of them taking their solution to the end users. Hence, partners need to support us and empathize with our team.
From the business any system that is rolled out, it has to have value in some form. Whether its improvement in clinical quality or reduction in my operation cost or make my people more productive, There has to be some associated business benefit.
The problem before and after is , before we take up solution to business, I should be able to prove or I should be able to at least articulate along with the partners how this will help the business in those parameters whether it is clinical quality or compliance.If it is compliance, It is critical.GST it has to be there, there’s no other choice. It could be compliance or clinical quality or operation efficiency or revenue.I need to be able to prove it is helpful to the business and the system should have the mechanism to show matrix around this.Many times, that’s a key piece we miss in many software.The matrix of the system, whether it is in terms of adoption, in terms of usage, in terms of usability in terms of business metrics. All the matrix should be bid to the system.
When putting the system in place, when my business asks the questions such as how are we doing? what is our ROI in the last one year? Here, I shouldn’t be scrambling that I got the system in place and people are using but what’s happening is not known . If I can’t figure out or produce some reports to figure out how the system is being used. It’s of no use. Such aspects need to be baked in the system. What’s my adoption level? What’s my business metrics? they need to be part of the system. So for the end users it is about the solution. For the business users it’s about the adoption and the business metrics out of it.
