Category: IT Compliance (Page 17 of 17)

The Problem According to TRIZ

As a former head of IT security running close to 350 security devices worldwide for DHL, I think I have a pretty good grasp of problem solving skills. We used to deal with tens of incident tickets coming in. Tens of tickets might lead to fewer problems, but this doesn’t mean it gets easier. Problems might end up being just symptoms of a bigger issue. The list goes on. Having passed the ITIL cert, I was curious on how we could better manage problem resolution. Incident resolution I get it. Just get the service up and running either through a workaround or resolving the underlying problem. The former is what I now know as the ‘sweet spot’, distinct compromises that has an improvement and a worsening factor. The latter is problem management, which I haven’t done too well. Try having half of China yelling into your ear to get those F5 BigIP load balancers to work properly so that delivery planes are cleared to take off, or face a multi million of USD loss per hour.

I would venture to say all incidents should be dealt with to get the service up, but should also lead to a more methodical problem management, to solve the underlying issue so that it does NOT happen again.

Over the weekend, I attended an intriguing course by a reknowned practitioner of TRIZ, who worked with Intel.TRIZ is a russian acronym, and stands for Theory of Inventive Problem Solving. I hear some of you going, “Wait, that’s TIPS.” OK, TRIZ stands for teoriya resheniya izobretatelskikh zadatch, which in Russian, means “Don’t-try-to-pronounce-it-and-destroy-our-mother-tongue” to most of us. In fact the real writing is in russian script, which, to decipher it, would probably take me about the same time to be fluent in Middle-Earth Elvish.

But that aside, TRIZ is actually a very interesting way to look at problem resolution. It’s a concept supported by its own tools to look into a problem in an inventive manner. Meaning, we’re here to resolve contradictions. For instance, to solve my computer’s performance, I increase the CPU, but with that, I need to improve my cooling fan. That’s a contradiction. When something gets better, something else gets worse. Immediately, you’d think, why not spend extra money and buy a bigger cooling fan? Using TRIZ however, it does away with experiential learning and simply breaks down the function, understand the cause and effect, and trim away areas that are not relevant, until it comes up with a specific “Inventive Principle” to address the problem. In this case, it might just be putting the computer inside your data center with special external cooling, as opposed to under your desk, stacked with moldy papers.

One of the idea of TRIZ is to break down the problem into functions and identify worsening and improving parameters based on 39 Systems Parameters. Then, using the contradiction matrix, identify among the 40 Inventive Principles how to resolve these. The philosophy of the 40 principles is taken from  thousands of patents, and how they address our needs. Apparently this is a conclusive list, and hasn’t changed since the 60s. That’s a pretty steady list.

After intensive training, we sat for the TRIZ certification exams and passed. So, PKF becomes the first management advisory firm with TRIZ certified people in it. A lot of it makes sense to me, as we always used to approach a problem in either a novel way or use our previous experience with the problem to address it. Both might or might not work, but with TRIZ, at least the alternatives are better mapped out.

Read it up in this WIKI, it’s quite an interesting concept; the world according to TRIZ!

 

Strange Tales from Auditing IT

“Hi, I am your IT auditor,” says the young lady before me. She is well dressed with unassuming colors, pencilskirt shaping her just enough without looking too informal. Beside her is an equally well dressed man. Or boy, more precisely. With those fashionably tall hair, waved as if he had just came out of a nearby hair salon, with those slightly tight pants, ending with shiny shoes with tips sharp enough to stab someone.

“Just show us where is our place, and your IT group, and we’ll be on our way!” she chirps merrily. After introducing her to my bleary-eyed IT manager, I went back into my austere chambers, decorated minimally, with plenty of space for the stacks of ring-files that documented my entire career as an Head Internal Auditor of XXYY company. And I waited. Surely one of these well dressed, articulate, young IT auditors will be asking me for a sit-down session on some of the perceived challenges of IT aligning with our business, and how we can improve. Surely, once she’s done mapping out the technical areas with my IT manager, she would surely come and talk to me about how the IT audit will be done, and how as the Head of Internal Audit, I should be aware of the findings and recommendations, since I was the one who hired her firm in the first place.

One day passed. No sighting. Maybe IT was really complicated after all, although the company’s usage of IT would have been pretty minimal, seeing that we only used e-mail mainly. We only had 3 guys in the IT shop running everything.

Day two, day three passed and finally, I decided to go down to IT and see what the heck was going on. My IT manager was there, as usual, obsessively browser surfing 10 different windows on his large monitor.

“Where are the auditors?”

“They’ve already packed up and gone yesterday.”

Flabbergasted, I went back to my room. So 3 days was all it took to do an IT audit? Who did they interview? Who did they talk to in order to understand the business needs, risks and processes? How did they communicate with the business without me knowing? What were we measuring? How?

They must have bypassed me and went straight to the business owners. That must be it.

Tapping the phone in front of me, I got hold of several of the stakeholders of the IT applications running in our company. All of them denied seeing anyone in a pencilskirt accompanied by a wavy hair boy. Some of these stakeholders would definitely remember anyone in a pencilskirt, so I guess they were telling the truth.

So the IT auditors were almost like phantoms. Ghosting in, and in 3 days, ghosting out again, never talking to any of the key stakeholders. How on earth did they do their audits then?

The above is a fictionalised account of an experience that was shared to me, on IT auditing. Although somewhat humorous, I still find it alarming that IT audits are still being conducted in this way: go in, talk to IT, sit them down with a checklist and get them to implement the checklist. There’s no context of the audit, no risk analysis, no understanding of the business flows, or how it interacts with IT. No comprehension of critical processes, or the role that IT plays in the broader aspects of business. They carry with them a pen and paper and a checklist, and goes in to the poor IT manager’s room and shoots him when he answers, “Umm, what’s a BCP?”, and shaking their collective IT auditor heads until the manager feels like a donkey in front of this pair, young enough to be his kids.

Checklists and irrelevant benchmarking.

IT auditors who do not take time to understand the context of their audits are wasting their time. Worse, they are disrespecting the customer. If a client has 3 people in his IT and generally use IT only for automation of processes, without too much dependence on it, why do you insist to flag a red flag of non-compliance to COBIT by saying they need to come up with an IT Strategic Plan? Or have a IT Steering committee? And what on earth is a non-compliance to COBIT? COBIT isn’t even a compliance standard!

We’ve seen our share of these “quack auditors” we call them, in our landscape. Of course, for every quack, we also find very good, self-respecting ones. But the quacks are the ones that gives IT audit a bad name. Suddenly people want to know if we do COBIT compliance. I even saw a proposal as thick as the Bible, expostulating to the client that they need to have all 318 control objectives in place, and the audit will cover ALL control objectives in a unified regulatory software. Which is a glorified checklist on excel.

It’s tough, and sometimes we compare our adventures in IT audits to wild wild western movies, where law and order was non-existent. Until we start educating and creating awareness in our clients on how to apply COBIT as a framework or as a compliance to a standard, and not a standard in itself, we’ll be seeing these quack auditors all over the place. It’s like someone exalting the miraculous cure of radioactive medicines in the 1920s, only for the patient to die from these quackery.

Entering into 2013, we would love to see some regulation on how IT audits should be done. In fact, as I always say, remove the “Technology” and just call it Information Security Audit. Now, who would you talk to about “information”, not “Technology”?

 

 

 

Newer posts »

© 2025 PKF AvantEdge

Up ↑