Digital Business Automation

It’s that time when I start thinking about what I’m going to write about for the next blog.  Some months, I won’t lie, it takes me a while to come up with a topic I want to write about.  This month, however, I have already written nearly 4 pages of notes on digital business automation.  It all started with one article that struck a chord with some blogs I’ve already written but got me thinking about several other issues too:

 “AI will give workers back two weeks a year, says research”www.roar-software.com October Blog

So many questions!  AI doing what?  What will workers do with the extra time?  How does that fit with Digital Transformation? Is it just about Digital Business Automation or will it need full Digital Disruption?  What’s the difference between the three? What about Digital Resilience? What even is Digital Resilience??? Lunchtime Yoga!!

Workplace Wellbeing

Those of you that follow my blogs, may recall that way back in April I wrote about businesses introducing lunchtime yoga as a way of trying to reduce workplace stress.  You may recall, that while I am not against lunchtime yoga per se (I actually do an 1.5 hour evening class every week), I feel that there are other approaches that could potentially be more beneficial.  I guess some of what I was getting at was the cultural shift that was really required (more on cultural shifts later). I have experienced businesses that introduce lunchtime activities driven by HR and designed to help reduce stress only to see them fail because management aren’t bought in, and employees don’t feel able to leave their desks to attend.  I suggested that a better approach to reducing workplace stress would be to tackle the main cause – overwork – and that one way of doing that may be to look at how tech could be utilised to reduce workloads for individuals. According to this research, using AI in the workplace could release 3.5 hours per week for the average employee. That would enable employees to take a proper break at lunchtime; to reduce the extra unpaid hours they put in arriving early or leaving late; give them thinking time; enable them to be more productive because they are not as stressed and overloaded.  It’s a win, win! BUT ONLY, and I mean ONLY, if a cultural shift also takes place to make all of those things acceptable in the workplace.

Workplace Culture

My working day ends at 5.30pm.  I have a boss who is very protective of his own free/family time and doesn’t expect anything different from any of his team.  Yet I still feel guilty when I pack up at the end of the day.  There is still a sense of dawdling so I’m not the first person to leave the building.  So deeply ingrained in me after all these years of working is the “can’t be seen to want to go home” attitude that even in a totally different environment, I struggle to shake it. Lucky are those of you who just pack up and leave without a care.

The culture of a company is so important and going to be even more so as the use of AI becomes more widespread.  There is a lot of scaremongering going on – stories in the media about how robots and AI are going to steal our jobs are an almost daily occurrence – but actually, this is a golden opportunity to improve our workplace wellbeing.

What would you do with extra time?

Of course much depends on how businesses view those 3.5 hours a day and some of that may depend on the drivers and motives for them undertaking the digital disruption that will lead to those 3.5 hours becoming available.  There are so many possibilities: a shorter working week; shorter working days; more manageable workloads; utilising the time created to upskill employees so that both they and the business can gain the maximum benefit from emerging technologies.

 

Digital Disruption isn’t just about the introduction of new technology, it is about introducing new systems and new ways of working, too.

 

More on Digital Disruption, Digital Transformation, Digital Business Automation and Digital Resilience in the next blog.


Walking into a doctor’s surgery and asking for penicillin

One of the problems I have found when adopting an agile approach to developing systems (and I mean truly agile, according to the agilemanifesto.org rules, rather than a particular project management methodology), is that the high level of end user interaction in the development process can sometimes lead to the users, in effect, designing the systems.  They often come with an idea for a technical solution to their problem and ask us developers to build that, rather than allowing analysts to design the solution.

I often use the analogy of a visit to the doctor’s surgery to illustrate this.

In recent times the old role of systems analyst or analyst/developer seems to have evolved into two separate roles – the business analyst (often with little or no programming skills or experience) and the software developer.  In our doctor’s surgery analogy, the roles of user, business analyst and software developer are fulfilled by the patient, doctor and pharmacist.   

It is the doctor’s role to investigate the symptoms, diagnose the problem and come up with a treatment plan, which they agree with the patient. It is then the role of the pharmacist to provide that treatment.

In software development projects, it is frequently the case that the patient (user) walks into the surgery with their own treatment plan in mind. They enter the room and ask for penicillin.  It is too often, in my experience, that the doctor (analyst) then simply writes out a prescription for penicillin and hands that over to the pharmacist (developer).

Imagine the case, where the pharmacist spots a problem with the treatment plan (say the patient has a virus), doesn’t think it is wise, and says to the doctor, “I don’t think this is right”, only for the doctor to respond with: “That’s what the patient asked for, give it to them”.

I’ve seen this story play out in many a troubled software project!

Even worse, I’ve often seen the equivalent of the doctor simply leaving blank prescriptions at reception for patients to fill in themselves and hand to the pharmacist!

The business analyst role is not simply to liaise between users and developers (I’ve known business analysts whose time was mostly taken up being an email relay, or a chinese whisperer!). They need to be looking at the business needs behind any request and designing a solution that fits with any current systems that are in place, before bringing that to a developer.

In addition, it’s rare that an analyst with no technical or programming experience will have the ability to know the full extent of what a software system can achieve, or design solutions that fit into existing systems well.

Maybe it’s time to bring back the combined role of analyst/developer.