SmartQA Community

Operationalising is key

(In this SmartBits, Zulfikar Deen outlines “Operationalising is key “. The video is at the end of this blog)

You need to understand industry like Healthcare where the primary job is not  use a system. For example, if in Healthcare or Finance or if it is a Finance or Back office operations where you got an army of people sitting. They are  actually doing everything in the system approving doing all that stuff. In Healthcare a clinician or a doctor or a nurse their job is not to work on a system,their job is to attend to patients. Whatever system I put in here for them to use it should be  non-intrusive. It should help them but it should be non-intrusive. 

That is the first understanding , whatever system when a partner is developing, you need to understand that this is not a primary tool for them to do that job. Now what is missing piece when I work with multiple partners is, you got a piece of the solution, that is great, it works, fantastic, but that is probably in my view no matter whatever technology architecture you put into the system. It is probably 20% of the effort. 80% of the effort goes in, how do I operationalize .

What do you mean by operationalize? The same example of a doctor, you made a small change, or you delivered some small incremental benefit. How do I let the doctors know? I cannot bring the doctors to the training room. I can not get all of them in one single place, it is not possible , whether they are nurses. So the change we propagated, how do I first of all make it reach them? That is the number one most important difficulty. 

Number two is in terms of support. let us say if they have a problem, now how do the entire chain of support system works in to the place , because when a doctor sees a problem in the application, hopefully it’s not clinically problematic application, if it is a clinically problematic it is going to be very very challenging. But even otherwise if it is raised, then it goes to a local support team, then they need to understand whether it is a problem of networks or application or system or server hardware, diagnose it rightly, then take it to the team internally and understand if it was a network problem, it was a infra problem, or it was actually application problem. Even if it was an application problem, there are ten applications interacting with each other, which part of the application actually created the issue, then finally trying to figure out it may be because of this part of solution then  forward the issue to them, then they need to understand.

For them the challenges of partner is in what sitting, in what situation this real problem occurred. In any clinical situation I cannot recreate this inpatient. I cannot give the patient data to my partner. so it is challenging for them to understand that also. 

Now not only understanding, making sure that support makes the fix or they give a solution it propagates through all through the chain and goes back to that particular end user is extremely challenging. So training is a big challenge, support is a challenge and adoption is a challenge . 

You may roll out n number of systems, how do I ensure, say we have twelve thousand people using a system. How do we ensure it reaches to them? and people have the inertia, so you bring a new what takes them to change. it’s going to be very difficult until it is driven. how we ensure that is we need to drive through the line of business leadership, they need to identify the value for it, they need to tell yes it is important  so by then one small change done by a partner in an application by the time I ensure this is the way for all 12,000 people, it is an enormous task, so that’s why that needs to be understood.

I being on the other side  I would say these are fantastic too, I got a nice little capability on the record,put some button up there, I got some good old report coming up. Why can’t the users use it. This is a challenge, it is extremely difficult to take one and propagate to 12,000 and do it continuously, so that is a critical piece of operationalizing versus developing a solution, 

It may not be about the only change in the software. it is about a process change. For example,we delivered a solution where a patient can do a payment by themselves lets say for  a consultation. Now earlier my internal process are lined in such a way that patient will come they will come to the front desk and then go to the cash counter they paid everything.  They’re all trained very well as a process point of view. Now, I suddenly introduce a system. From my partner point of view it’s easy, I got a payment solution for you, just go pay for it credit card integration, it’s easy, but now how do we train all my staff to know that somebody actually already paid that means they should have the knowledge, how do we change the workflow within the hospital, don’t have to hit the front desk. you don’t have to go to the cashier counter, you can go to the nursing station. How do I change that process? When going to the nursing station, the nurse should know that earlier they will have printed sheet, that they paid for it from the cashier counter, nursing should know, now it may not be the case, they could have been paid online. So they should be able to know how to look up into system that this person has already paid. Now how do I identify this is a person, so there are quite a bit of process challenge.

10 mindsets, 10 tips & 10 habits to clean code

T Ashok @ash_thiru on Twitter


A mashup of three articles published as part of SmartQA digest over the last few months that outlines mindsets needed to brilliant code, tips to produce clean code and habits to speed up evaluation

Here is a mashup of three articles published as part of SmartQA digest over the last few months that outlines mindsets needed to brilliant code, tips to produce clean code and habits to speed up evaluation.

10 mindsets to deliver brilliant code

Great code is not result of mere unit/dev testing at the early stage. It is really a mindset that is key to producing brilliant code. 10 things to be sensitive to deliver brilliant code outlines ten things that a developer should be very sensitive to enable the delivery of brilliant code.

10 tips to clean coding

10 Simple Tips to Clean Code has in detail, simple practices that can ensure that code developed is constantly cleansed. In current times where code is churned out at a rapid pace, it makes great business sense to contain the entropy continually. 

10 habits to speedy evaluation

Automation is a key enabler for rapid QA, the limiting function to speed is one’s skills. And this is where good habits come in. 10 Habits to Help You Speed Up Testing outlines these in detail.