Tagged with software

Positive internal audits

Credit: http://www.independentaudit.com

Disclaimer: Honestly, I really wanted to write this post a long time back but I keep having difficulty framing this one idea. Not because the idea wasn’t very clear in my mind but because I don’t want to look like the guy who bit the hand that fed him for the last 4 years. Secondly, I have huge respect for all my ex-team members who had worked with me during that period and again, didn’t want to end up looking like a guy who criticized them for the job that they did.

I remember my first internal audit engagement at one of my firm’s clients. I was given a checklist of specific things that needed to be checked, an-indepth discussion with my seniors on how each item/ process was to be reviewed and what were the potential gaps in the process I could be expected to find. I spent a total of 3 weeks at the circle (telecom companies have different circles or geographical regions which are responsible for operations in that specific state) and basically wrote a report on all the stuff that the client needed to improve on with respect to that specific process. And then we gave them an overall rating on how the level of control implementation. Then I went on to the next circle and the next area and repeated the same. It was a hectic period and by the end of it all, there were two things I realized even about myself: One was that I had learnt an incredible amount of stuff about telecom operations on a relatively steep learning curve and the second was that I had personally become a lot more observant but a lot more critical about how things worked in general.

The next year, the process repeated and I started running around in circles again (pun intended). But this time, one comment from the head of the Customer Service (CS) team (who was the auditee) stopped me short. “Why do you guys always write negative things in your report? What about all the good things that we have done in this circle?” I blinked my eyes for a bit and then mumbled an explanation about how audits were exception based and reports were designed in a way that if exceptions in a process were not reported, then it meant everything was fine within the process.

But I couldn’t get his words out of my head. He was absolutely right. They obviously had an SOP (Standard Operating Procedures) manual to follow, but there were several times, I had seen some brilliant processes or activities that were being implemented which was not required by the SOP. For example, one of the circles came up with the idea of a brilliant IT-based tracking system that drastically improved their controls over the distribution network. However, it required the corporate IT team to develop it rather than the circle IT team. Now, the typical process for a product like this was that the circle CS team raised a request to the corporate CS team, who then approved and forwarded it to the Corporate IT team. But because of the general lack of harmony between the various corporate teams, this always got delayed. To bypass this, the circle CS team sent this request to the circle IT team which forwarded to the corporate IT team. Now, since the IT team was outsourced, release of such products gave the IT firm the credit for the product launch/ idea informally. So it became a priority for the corporate  IT team. And got launched really really fast at the circle.

The problem? 6 months later, I had gone to another circle to perform another internal audit and saw that the product was still not being used there. Why? Because despite the sales team breaking their heads asking to launch the product in their circle, it was still not being released by the corporate team. It was ridiculous. But what really struck me was that none of this reflected in my report – either in the original circle report where they had launched this nor in this circle report as a serious requirement not being catered to (it had be later modified to be included as a recommendation). Why? Because we did not track intra-client, inter-circle benchmarks. Rather, it was only about whether a risk was controlled or not; not comparing the amount of effort it took between two different methods to do the same. And since we were one of the very few independent parties that actually commented on the efficacy of the process, there was no other external, non-partisan process by which these brilliant ideas and products were being communicated across various circles of the client. So there were two takeaways: First, no credit for positive exceptions (Where the circle team had done something really outstanding and drastically improving the efficacy of the process) and the second, not checking whether other teams were actually taking advantage of the fact that some creative people in their organization had come up with something really impactful

Somehow, I feel that there has to be a positive aspect of internal audit beyond playing the devil’s advocate. I’m not saying it can be done with the same team strength and the same time-frame that internal audits are conducted in today. In fact, looking back at the hours I put in and the hours that some of my friends are currently putting in, I’m saying it cannot be done with the same resources. But it can be done. Simply put, there needs to be some kind of process by which interesting, creative and real problem-solving activities done through the circle’s initiatives are accumulated, classified, deployed and checked across other circles:

Accumulation of data: Identify the activities that are gone beyond what the SOP has documented.  Detail the activity performed, date of launch, expected impact, observed impact and the personnel involved in the product design. I think this step shouldn’t be too difficult especially given that people would love to tell you all the creative stuff they have done if it results in visibility to the top management.

Classification: Segregating the activities based on system, non-system based process, department, high impact/low impact, etc. This is where the independent, expert, non-partisan view of an internal auditor kicks in. In fact, if this is a separate report, a rating system (similar to the rating in normal IA reports) can be developed to recognize the efforts of various circles’ various departments.

Deployment: Discussions with corporate teams on which activities need to be implemented on an immediate basis, which one year later, and time lines for the others. Discussions with the circle process/product developers on pros and cons of the process/ product and the process of covering up pending deficiencies with corporate support. Communication to the remaining circles with clear instructions on implementation guidelines and probable areas where issues may arise. Finalization of rewards/ incentives for really really innovative stuff.

Checking: This is part of the current internal audit itself. So not only does the IA team actually check if there are risks which are not controlled leading to a revenue loss but also the status of implementation of these activities (simply -  implemented or not implemented; no need to comment on phase-wise status). And it would be a rolling implementation i.e. what was supposed to be implemented in year X is audited in year X+1.

And that’s it!

I think this seems to be a much better way to do things. After all, no organization has the manpower to actually implement the whole thing I described above in-house. Hence, they need consultants to build this process out.Even if companies do build an intranet module to accumulate and categorize suggestions, the deployment stage is usually where everything begins to fall apart. (Flashback: I remember this one circle where they had actually implemented a website (on the intranet) wherein people from various departments contributed various ideas to improve their processes and were rewarded for the same. The best part? That site was accessible only to people of THAT circle. Not even to others in the same department of other circles of the SAME ORGANIZATION! I can imagine some consultant came in, checked that site and used some of the suggestions to design best practices as well :) . I did the first two steps. It made for incredible reading !) Further, they need process experts who may be able to riff over the new process and making it even better. So consultants/ IAs can either build it into their existing service or as part of another engagement, whichever works better.

The funny part or the real proof of concept? People actually engage consultants for business process re-engineering engagements to help them implement the best practices (sorry for the jargon!) that are followed by their competitors or the leading players across the world. This without checking their own innovation cupboards to see if they have the equivalent of a “next practice” or what would be an even better way to do things! So you can even put the accumulation, categorization and deployment stages as a BPR engagement and the checking stages as the IA part.

It just seems that internal audits tend to take a bad rap as being too documentation-oriented, too rigid and basically too its-in-the-outdated-SOP-so-if-you-don’t-do-it-it’s-a-gap mentality (especially from me! :) ). Not all IAs are like that (and definitely my ex-organization didn’t practice it that way) but some aspects are. And I think this is a better way to move away from that perception/reality than justifying it by saying they play the devil’s advocate

P.S: Those who know me well enough may read this as a softening of my “documentation-of-processes-is-crap” stand. It isn’t. It’s more of an example of this method :) . It’s one step forward to my final “documentation-is-crap” post (whenever that gets written).

Tagged , , , , , , , , , , , ,

Serge Ferre on Why Nokia Should Focus on Solutions Instead of Apps « Gauravonomics Blog

Interesting link. Serge Ferre, Nokia’s Director of Strategy talks about first building what he calls solutions before starting building applications. Well, honestly, I don’t really get the solutions concept. Is he talking about a platform or a categorization basis? I doubt he is talking in terms of platforms. There seems to be some kind of pyramid of platforms being created. First you just had the handset and the basic functionality, then you added the Symbian OS, now they wanted add a third layer of platform such as Music, Maps, Life Tools, etc. and then deploy applications on top of that.

Doesn’t it make sense just to use tag architecture to tag various objects as Music or Maps rather than create another platform

via Gauravonomics

Tagged , , , , ,

Two levels of expertise

There are four levels of expertise in mastering any software: Beginner, Intermediate, Expert and “I use only keyboard-shortcuts”

Tagged , ,

So what does DNA, astronomy and engineering have in common?

Elegance !

Have been parallely reading four or five books (Frankly, it drives my mom mad to see so many books scattered around)

1. DNA – James Watson

2. The Theory of Everything – Stephen Hawking

3. Buy.ology - Martin Lindstorm

4. Electronic Devices and Circuit Theory  - Boylestead and Nashelsky

If you have been a dedicated engineering mugger, you would have recognized the last book as a required reading for the circuits theory exam. I can see you going “huh?” over there.  Let me explain that later.

So what is this post about? Parallely reading these books has made me realize something incredibly significant. Anything that has been discovered about living creatures (see this TED talk: Janine Benyus shares nature’s designs Amazing !) , DNA studies or even outer space (the way galaxies, solar systems and black holes interact), there is one common thread running through them all. The explanations are based on logic so fundamental and concepts that are so simple that it is a revelation unto itself.

“It was so simple, so elegant, that it almost had to be right” – James Watson on discovering the DNA structure

Similarly, Stephen Hawkings explains the discovery of black holes and the explanation using such simple concepts that you can understand it even if you are an engineer (that is not a typo :) .   This made me go back to my engineering references  (not local authors obviously) and checked whether I missed much in the 4 years I did my engineering. The answer is “a lot”.  While I have just started reading these books, it is quite apparent, that engineering has also been based on some incredible science; science that it’s base works on the manipulation of electon flows. The entire world of electronics then depends on the control of the flow of these electrons. Much like a traffic policeman (but definitely more effecient and less susceptible to bribes) , circuits amplify electric fields, magnetic fields (a moving electron generates a magenetic field) and manipulate this flow into more usable features.

When we think about all this, it made me question that when nature’s incredibly complex creations are based on such simple foundations, why are man-made solutions so complex? Whether it is our business processes, our operational processes, our policies and procedures, our accounting standards and hell, our relationships ! Hey, even our software programs. Why do we feel so empowered when we complicate our language, when we complicate our behaviour, when we complicate our manuals, our lives and our design approaches. Does it make us feel like we’ve done something no one else could? Why do we add features on a product that no one wants? While adding redundancies in a system is OK, where do we draw the line and say “Hey, that’s way too complicated”. I have come across this so many times during my audits when the recommendations we give have a response of “Haan! Par iske liye software based tracking chahiye” I remember discussions of a  process of new products launch wherein the Marketing head said “The ideal process should be to setup the whole process as a system-based workflow”. It just struck me that one of two things was happening (both incredibly bad):

1. The process was way too complex requiring 10 different approvals both at the circle and the corporate team

2. Instead of questining (1), we try to upload the problem on IT systems to make things “faster” and “more documented”.

Anyone who has read IWoz (Steve Wozniak’s autobiography) will be a fan follower of the Woz for life (and vice versa). Every approach of his simple and elegant. Half the reason for that was that he never had the computer architecture/ processing power/memory while designing the Apple 1 that we have today. Hence, that limited the number of lines of code that he could enter for a specific program, the number of transistor circuits he could use in the architecture. And that created the elegance of the Apple 1 and the Apple 2 (plus Woz’s incredible God-like powers to simplify system architectures and applications that no one else could). That constraint was one of the reasons that even today, Apple has some of the most elegant and frankly, non-crashing software platforms available in the computer industry.  Now, that we have this incredible computing power, everyone irresponsibly writes bloated code on bloated middleware leading to bloated application. This is just an example of application development. Look at any of the things you do and you will see “bloatware” everywhere - things that need not be there but are. Cars with features you never use; hard disks with data you never see, hotels with appliances you never see and definitely, my personal favourite, processes with controls for risks that will happen once in a lifetime.

Overcomplicating things is just a result of mental lethargy. It seems that the “chalta hai” attitude has permeated even our “professional” committments to the point that as long as it works who cares whether it consumes more resources that it needs to. Technology has easily outpaced our ability to simplify. Maybe technology has just amplified our inability to simplify. Who knows?

Tagged , , , , , , , ,
Follow

Get every new post delivered to your Inbox.