Improving It

Processes patterns as predictable as Mexico City rain

phil_ayres@hotmail.com (Phil Ayres) — Sun, 19 Jul 2009 20:00:32 PDT

Mexico City, another wet afternoon

Three months, two business processes, one client with a new system in production. And I'm not talking about some irrelevant back-office processes. The Technolab team have implemented, for the Mexico division of a major international life and medical insurance company, a BPM system for processing new policies, policy renewals and maintenance, from client request through to payment.

In three months, we've taken the blueprints for current state processes from the business analysts and designed, built and deployed a system that should see huge benefits for the company and its employees. And at the end of it, the one prediction I made to myself came true. Business processes fit one of three patterns, and I only like two of them:

Straight Line
Single Step / Star
Structured Chaos

When I lead process projects, as I did this one, I tend to guide the client to one of the first two patterns, since they tend to reflect the reality of the way people work and lead to a successful, usable and subsequently easily adopted (by the users) system.

Let me quickly talk through the three process patterns.

1. Straight Line

I love it when a process turns out to fit this pattern. Its exactly what you are trying to achieve when you improve a business process; a process that starts cleanly with a specific outcome in mind, and with minimal deviations that always try to return to the main path as quickly as possible. Why is this good? Because its easy for users to understand, and its clear what the fastest, most efficient set of operations is. A company can build key performance indicators around this, since its easy to measure progress of work through the process.

2. Single Step / Star

How can I call this 'single step' and 'star' in the same breath? This process pattern really revolves around a key single step where the vast majority of processing is done. The steps outside of this often represent exceptions or sub-processes, so much like the Straight Line, they are deviations. And although I say this is single step, the reality is that the work may well cycle around this 'step' many, many times, being delivered to different people and roles on each revolution. But since there is little way to enforce the order of this work (at least with the time or money available to re-engineer the process), while still allowing users to get the job done, the process pretty much becomes an orderly way to track work as it passes between users, with delivery under their control.

3. Structured Chaos

Its when project teams try to force fit a process on top of current operations without effective analysis or change management that I think you see the third pattern. Note I say effective analysis, since there may still be a large amount of time spent on it to produce this result. And there is a chance that is may just work in practice. This is what BPM tools strive to be able to represent, and the temptation is therefore to go with the flexibility they offer. But to me, this process pattern shows a poorly thought out scope for the process. In other words nobody has defined what the process is actually trying to achieve and what type of work it is trying to handle. The more steps and decisions you have to add to manage the necessary requirements of the process, the more likely it is that you have missed one. Often, if a prototype process starts to indicate Structured Chaos, it may be time to rethink, and split the process into several Straight Lines, or possibly one Single Step / Star.

So at the end of three months, what have we arrived at? Well, I'm sure I would not be telling the story in the same way if it was structured chaos. We have deployed a nice clean Straight Line for one process and a nice Single Step / Star for the other. The end result is deceptively simple, and perhaps as much time was spent getting us to this result as actually physically implementing software. Which is great, as the processes will work fast, there is a lot less to go wrong and a lot more flexibility to handle the 20% of cases that don't quite fit strict rules.

Maybe BPM vendors would relabel Structured Chaos as a beneficial Complex Process. It all comes down to how you market your capabilities and limitations. Still, after 12 years of doing this stuff, I haven't seen a customer happy when you finally deliver them Structured Chaos. I'll stick with my two successful patterns, and leave the 'anti-pattern' to the BPM marketing departments and services teams.

A post from the Improving It blog

The joy and pain of rolling out a new business system

phil_ayres@hotmail.com (Phil Ayres) — Sun, 19 Jul 2009 19:53:32 PDT

As three months in Mexico City draw to a close, the business process management (BPM) based system we've been building is heading for production. Not wanting to risk jinxing it (so there is a lot of wood touching happening here), I am trying to avoid saying that it may possibly, if the stars align, be on time and to budget. Technolab and the large multinational insurance company that we have been working for should be proud, as even if we do see a last minute hiccup, the teamwork and desire to get the job done has been incredible. So, that's the joy over with. What about the pain?

The pain (at least for me) comes from the uncertainty; the last minute unexpected mishaps; the possibility that the production servers just won't run right; the fear that integration with the system of record is just not the same for production as in dev and test; the fact that I'll have to perfect meditation to try and sleep without my brain going over every last detail (again). Dreaming software is not fun or relaxing. Especially not dreaming it in a foreign language!

But its just an application, right? And its been tested?... Of course.

Its the fact that the system touches the working lives of practically every skilled worker from sales, through underwriting, to policy issuance and accounts receivables. If the system screws up (like throws every item of work into an error state) for some unforeseen and therefore untested reason, there's going to be a lot of people sat on their backsides drinking coffee and waiting. That would not be the ROI that we all hope for. But its not just this project. For me, every system I've deployed (more successes than mishaps, it has to be said) leads to this mix of adrenalin and some other unknown compound (probably caffeine).

So for now, all I can do is keep on using the revolving brain, mentally touching and prodding every last piece of the processes and applications, to satisfy myself that everything is good. Reality is, its been good for a while. We have settled, just in time, into the essential phase of stabilization and risk reduction. So I'm ready for some joy on Friday. Just a little. Seeing the first users successfully login and start working full time, full on, with their new system. If so, you could see a deliriously happy post from me at the end of the week. Please keep your fingers crossed! Mine are, and its making it difficult to type.

A post from the Improving It blog

Download the podcast of this blog post

Testing times: changing perspectives in an agile development cycle

phil_ayres@hotmail.com (Phil Ayres) — Thu, 09 Jul 2009 20:47:03 PDT

Testing software, in the form of products, custom applications or BPM based process implementations is surprisingly very different. I watched skilled, professional testers provide amazing coverage of a product in my previous life as product manager, with automated tools preventing regression. I've been part of teams building custom business software, then working hard on testing that software so it gets through the final user acceptance without a hitch. Right now I'm working with a client to ensure that the BPM and Case Management solution we built, following an agile methodology, not only meets user requirements, but works without fail. It is this last one that has presented some interesting challenges. How do you transition from an iterative, modified scrum development model, to the formality required to ensure the solution that has evolved just works? This is hard for the analysts and end-users, and surprisingly for the developers as well.

The head of the systems group pointed something out to the team of end-users who have been working with us on the project since day one, and who have now been enrolled as testers. Paraphrased (fortunately, because the Spanish translation would have been bad) he pretty much said,

You've had your chance to say what goes into the solution. Now test what we've been delivered, not what you wish you'd asked for 6 weeks ago. Now is not the time to be suggesting new requirements, or complaining that some things are more difficult to do than you would have hoped. If you can work around a limitation or restriction, you will. Feel free to note potential improvements and we'll rank them for phase two. If the solution does not work, throws an error, or completely blocks work from moving from one activity to the next then your tests have been successful. The aim of this exercise is to come out the far end with a system we can be confident will work in production.

I have a lot of respect for that attitude, especially when it comes from the guy who is paying the bill for the solution that is delivered. Pragmatic, realistic and most likely to lead to a project that is delivered to time and budget, while meeting 90% of the user requirements. It also helped the end-users adjust their perceptions from creative and business minded analysts, to logical and step by step testers. They are testing with real data and documents, which will hopefully uncover any hidden data level issues, but will the test cases cover the 90% of insurance underwriting tasks they have to cover day to day? If you see the work-arounds they have to do today with their paper and 'systems', you'd think it would be hard to fail.

We have one thing on our (the consultants') side, which is the same thing that always represents a risk. The previous paper process effectively had no automated controls, but because of that it meant that you could do whatever was needed to get work done. We've added some controls and rules. In fact over the course of the project we've added, then refined, and finally removed many more. As expected, at the start of the project the appeal of being able to control and restrict a process and its flow was exciting for the users and analysts. They define many things that they realize later on just won't work in practice. The trick to this is helping them understand that this is a step forward from today and flexibility is a positive thing. And fortunately it means that the likelihood of testing failing due to poorly implemented, highly complex rules is much reduced.

So, my beloved user testing team, please beat up our solution this week, with logic, flow and some flair. 'Cos its a damned site easier to fix big problems now than after go live!

A post from the Improving It blog

BI and BPM is more than slicing and dicing your workers

phil_ayres@hotmail.com (Phil Ayres) — Thu, 02 Jul 2009 20:49:40 PDT

What does Business Intelligence (BI) get a business? Incredible insight into the performance of the business, its operations and the impact these things have on the bottom line. Which is great, until it shows that certain parts of your business are really messed up or just extremely unpredictable (which when you are trying to achieve consistent results can be a problem).

So what do you do now? Find a way to improve the performance and repeatability of business operations and find a way to get visibility into the opaque areas that are causing you so much unpredicatability. Both of these are targets for Business Process Management (BPM) tools, since improving and automating processes can provide huge benefits in the way operations run. Great story. The end... But not quite.

Its okay. I don't have a marketing team watching over my every word, so I don't have to claim that BPM solves everything, since it doesn't. Vendors and consultants forget that BPM needs to truly be part of the BI landscape. And not the vague attempts some BPM vendors have made by trying to force fit analytics tools onto process engines to provide in depth slice and dice information on the performance of individual workers. In my opinion, this is missing the point.

What do I mean? I'll answer a question with a question. What value is there in pumping basic activity timing information from your BPM engine into a multi-dimensional cube so you can analyze the crap out of an individual step in a process, when you can do much of the same with standard BPM database tables, and an Excel pivot table? Unless the process represents millions of items a day, the level of scrutiny that analytics can provide at such a granular level is potentially misplaced. BI is not just having a cube and putting some pretty visualization in front of it.

Here is what the true intersection of BI and BPM is in my opinion. It is the ability for BI to help you identify where in the business you can see problems, then using BPM to rapidly:

Design, implement and run improved processes to help fix the problem
Provide visibility into the work inside the process at a point in time with real business metrics such as the value, risk and profitability of that work
Enable individual work items to be profiled and prioritized (against these business metrics) to drive the process towards greater profitability or revenue
Track information that can rapidly feed back up to your core BI, to show how performance and business metrics are trending

Using all this great BPM value, make sure that BI shows meaningful information from it. Down in the business operations, a KPI is maybe that the average time to process a specific three steps in the process has trended above 15 minutes 53 seconds. The manager there can work with that to fine tune the process. But I don't suppose the guy with a corner office 12 floors above really gives a crap. His question is whether the same operations are going to hit a profitability of 18.5%, a growth in revenue of 6% and reduction in costs of 2.5%. And what the hell can be done about it if it appears that's not the case, because that's one thing that will impact his bonus.

BI and BPM are complementary at many levels and should feed each other in many directions, and it takes more than a software vendor to make this a reality. Implementing both technologies to best effect in their disparate business environments, while ensuring that the sum is greater than its parts is a challenge. So maybe it is time for a few more consultants that understand both BI and BPM to help companies really see the potential.

A post from the Improving It blog

Download the podcast of this blog post

P2P payments without the PayPal

phil_ayres@hotmail.com (Phil Ayres) — Wed, 24 Jun 2009 21:19:32 PDT

I had never thought of alternatives to PayPal that maybe my parents would trust. When it comes to sending money around, people are rightly cautious when it comes to the use of third-party services. And unfortunately PayPal has become a target for a large amount of phishing scams, unfortunately hurting their image through no fault of their own. It seems though that other people have been thinking of alternatives.

Yesterday I received a message from CashEdge, (who I mentioned in this blog in 2006 and it appears their PR team still has my name on file. The power of PR; it got you another mention!). They are talking about an new approach to person-to-person money transfers that could be offered by banks - i.e. the bank you already know and trust with your hard earned cash. It certainly sounds appealing. So what's the deal? According to CashEdge:

Today, CashEdge launched the first person-to-person payments service for banks – POPmoney – that will enable consumers to send email and mobile P2P payments directly from their bank account to friends, families, and others, using only an email address or a cell phone number. There has been a lot of buzz about P2P/mobile payments recently, but CashEdge offers three critical advantages: 1) POPmoney is the only service built specifically for banks; 2) CashEdge has a proven record of success in providing risk-management money movement services to the top national banks; and 3) unlike other payment networks, banks have a built-in customer base (current bank customers) for this service.
http://www.popmoney.com/media.html

So this sounds like a good idea for US banks, which are still tied to paper checks (cheques) and are desperately trying to find faster ways to move consumers away from them. It sounds like a potentially great source of new revenue which is effectively lost today to PayPal. And from what little I know of CashEdge, they have the ability to provide this solution to mid-tier banks that don't want to build it themselves, as a software as a service (SaaS) offering.

For me what will make or break it is not CashEdge, or the announcement of an offering that does not expect to have customers it can name until the summer (in which hemisphere?), but the pricing that banks attach to the service. Will they try and undercut PayPal, or will they charge a premium, knowing that mom-and-pop wouldn't use PayPal anyway. Go too high and mom-and-pop, with plenty of time on their hands will probably write that check, stuff it in an envelope and put a stamp on it.

Good luck CashEdge, but I'll believe it (POP) when I see it unfortunately and will happily continue using PayPal for now. That feeling is only reinforced by an announcement that seems way too early, or at least a missed marcom opportunity in the buzz and advertising strength of a bank saying, "Use our great (POP) service" and other banks saying, "How do we do that?". The credibility of P2P payments (at least in the US) rests with the banks, and their adoption of CashEdge, or other vendors that have been pre-warned that they have until the summer to make an announcement first.

A post from the Improving It blog

Download the podcast of this blog post

Tools are 'temporary body parts' (so pay attention to application design)

phil_ayres@hotmail.com (Phil Ayres) — Mon, 22 Jun 2009 21:09:30 PDT

The BBC News website had an interesting story today: Tools are 'temporary body parts' The researchers writing in Current Biology showed some interesting, if not completely surprising results that after using a tool for an extended period of time, your ability to perform similar tasks without the tool become slower and more 'clumsy'.

"There is a great debate in neuroscience about the representation of the body and representation of space," said Lucilla Cardinali of the National Institute of Health and Medical Research (Inserm) in France.

The researchers were working with a metal grabber and seeing how its extended use affected the user's ability to grab things without the tool. Imagine the damage we do to our ability to perceive our own bodies and perceive the space around us after hours tied to a computer keyboard and a screen 2 feet from our faces. Go further and try and see the confusion of a human brain after extended use of Twitter, IM, phone, Facebook, etc. How confused is a brain in truly perceiving the relationship between location, timezones and human behavior; especially as every one of these mediums cuts us off from the real interaction that we have evolved to trust and enjoy in human relationships.

Now go one step further. Give a person in an office a new software application to use to do their day to day work. More than just email, but for example a new tool for creating quotes for an insurance underwriter. If as a person you are absorbed in that application to do your job, you adapt to the application's shortcomings and come to appreciate its strengths (or perhaps unknowingly adapt to things you just happened to find useful).

I watched the joy on some user's faces just a few days ago when we showed them a demo of a new software solution. They have been doing copy and paste of information between systems for a long time. One tiny piece of our new solution has a built in search with their main system, and the ability to click a result to use that directly in a new piece of work. A simple click and the smiles were shining.

The function took 5 lines of Javascript and some configuration. And it will probably be the most loved piece of the overall application. The users will hopefully come to adapt to (and therefore not be able to live without) other pieces of the solution, though its important to see how such small details can make tools so much more an extension of a person and lead to improved acceptance and productivity.

A post from the Improving It blog

Download the podcast of this blog post

Will the EPA block regulation on Carbon reduction?

phil_ayres@hotmail.com (Phil Ayres) — Sun, 21 Jun 2009 07:57:01 PDT

According to the WE campaign (we can solve the climate crisis), the Environmental Protection Agency (EPA) has the opportunity to facilitate, or to stand in the way of, future regulation of Carbon emissions. This could strongly affect Obama's capability to influence climate change through regulation:

The EPA recently released a finding that would allow the Obama administration to limit carbon pollution. But it’s not final until the public weighs in and the deadline to submit comments is this Tuesday.
http://www.wecansolveit.org/page/s/epacomments

Based on this very sparse information, I wanted to find out a little more. Here is the result of scouring the web to find what is actually going on. The most understandable information I could find was based on a public hearing led by Dina Kruger, the director of the Climate Change Division at the EPA:

[on the EPA] proposal that finds that greenhouse gas emissions endanger human health and welfare, and that greenhouse gas emissions from new motor vehicles cause and contribute to the climate change problem under the Clean Air Act.

The EPA is unable to make any rules until all stakeholders have a change to comment. Stakeholders include car makers, big-oil, lobbyists and one or two hundred million individual citizens. The rest of the several billion people in the world affected by the decisions of the EPA are not represented.

How can people put their opinions forward? Visit the EPA comments page on the WE website is one option. The EPA website also hides away how to comment directly. Go to the bottom of the page: Regulating Greenhouse Gas Emissions...

For those of you wanting a little more background, I found this brief history (dating from 1999, with all the action in the last 2 years) of Carbon legislation at the start of the Public Hearing document.

In 1999, EPA received a petition to regulate emissions of four greenhouse gases from new motor vehicles and engines, under Section 202(a) of the Clean Air Act. EPA denied this petition in 2003.

A lawsuit was filed, which resulted in the Supreme Court decision in Massachusetts v. EPA, in April 2007, where the court rejected EPA's reasons denying the petition, and found that greenhouse gases are air pollutants under the Clean Air Act.

The court stated that the EPA administrator must follow the statutory criteria of Section 202(a) and make a determination regarding the role of greenhouse gas emissions for motor vehicles in contributing to the climate change problem.

The options for this determination were either that greenhouse gas emissions from new motor vehicles do cause or contribute to air pollution that may reasonably be anticipated to endanger public health or welfare, that such emissions do not cause or contribute to a threat, or that the science is too uncertain to make a judgment.

In July 2008, in response to the Supreme Court's decision, EPA published an Advance Notice of Proposed Rule Making on Regulating Greenhouse Gases under the Clean Air Act. This ANPR made no determination regarding endangerment but rather requested comment on the implications of making an endangerment finding, and the underlying science.

On April 17th, 2009, after a thorough scientific review, Administrator Lisa Jackson signed the proposed finding that greenhouse gases contribute to air pollution that endangers the public health and welfare of current and future generations.

The proposed finding identifies six greenhouse gases that are reasonably anticipated to threaten public health and welfare. The proposal also finds that the combined emissions of carbon dioxide, methane, nitrous oxide, and hydrofluorocarbons from new motor vehicles and motor vehicle engines contribute to the atmospheric concentrations of these key greenhouse gases, and hence to the threat of climate change.

EPA's proposed finding does not include any proposed regulation. And before taking any additional steps to regulate greenhouse gases under the Clean Air Act, EPA would conduct appropriate rulemaking process and consider stakeholder input.

Massachusetts - a low lying state is threatened by Global Warming, with the chance that it will lose a large quantity of land and housing (currently inhabited by tens of thousands of people) if sea levels rise. I'm one of them! Now perhaps this proposed regulation is an opportunity for those people, with the population of the other east and west coast states, to get together and save their environment and their homes, and the lungs of everyone from more airbourne pollution.

A post from the Improving It blog

The missing link

phil_ayres@hotmail.com (Phil Ayres) — Sat, 20 Jun 2009 11:37:03 PDT

I don't know when it happened, but the evolution of building software applications for business, especially those based on business processes and BPM, has led to a missing link. Not a sub-human creature of limited intelligence, although certainly a large gap in knowledge and capabilities inside the teams that define and develop solutions.

Leading a recent business process management project, I ran across this missing link several times. And it has led me to compare the profile of the software projects I was part of maybe ten years ago. Back in the good-ol'-days, software projects seemed to have a nice neat demarcation of roles: the business analyst worked with end-users and management to define the requirements that fed the current needs of the business and the perceived improvements; a software architect worked with the business analyst to translate these requirements into a software architecture of blocks, arrows, UML, and written specifications; finally the developers worked with the architect and (if they were senior and knew how to tie a tie) with the knowledgeable users to work out and eventually code software logic.

With BPM, the missing link has evolved through the pressure of vendors, industry analysts, and probably financial pressure in organizations wanting new software solutions cheaper. The roles have morphed as vendors and analysts tell companies that their business analysts can define and build workable processes without the help of their IT team (although see my post: Your 'Systems Group' is the reason you business teams (are) disintegrated if you want to see why I think that it wouldn't work even if your IT team was involved). The reality is that with the right tools, business analysts can build working processes, though they probably don't want to, because real (rather than just workable) business processes are hard, detailed, time consuming beasts.

So what is the profile of a team in the modern world? A senior business analyst has turned highly strategic (maybe because there is more caché in a hand-waving strategy role?), but still gets his or her hands dirty from time to time defining high level processes using a vague understanding of something BPMN-like. A more junior business analyst takes some of the concepts and tries to make a vague guess of how this maps to the details of the business. The great leveller of industry standards says that if you use BPMN you are sure to get a best practice result (I lie), and then fill in some spreadsheets for the other details you find out along the way that might just be useful. Now throw this information at a consulting firm's expert in your chosen BPM product, telling them that the analysis is complete and there is no room in the budget for further analysis, so just get building. Actually sounds very Dilbert-esqe.

What is happening? The software architect role is the missing link. He or she was carefully superseded by the enforced architecture of the BPM foundation the solution will be built on, forgeting that there was more to the role than blocks and arrows. The business analysts do not really know how to interact with software developers, since their contact has only been with senior strategy people they one day aspire to be, so the level of detail they are able (or willing) to collect is variable. But they try. The consultants are therefore forced to try and meet in the middle by wearing the hats of architect, process analyst, business rules analyst, process designer and software (at least customization and UI) developer. With top quality, highly experienced consultants, there is a good chance that they will fit the gap without a nervous breakdown. For less experienced consultants (or maybe worse, consultants highly experienced in traditional software lifecycles), the gap and constant flux in project requirements, definitions and uncertain rules can be highly jarring.

So, who wants to evolve to be stronger, better, faster, and take some of the traits of the extinct software architect? I don't know - and I'm open to offers from anyone who has seen this pattern in projects or believes that the architecture role is still alive and well. My guess is that the profile of projects I've been involved in has led to the customer not wanting to pay for the people I mentioned: process analysts and business rules analyst. Or maybe there still is a software architect role in BPM under a different name.

Either way, this trend of half-hearted, strategy rather than details-oriented business analysis, coupled with do-it-yourself process developers, seems to present a big risk to BPM projects. There are a limited number of BPM implementation experts out there, so if you want to implement a BPM solution, pick well!

I hope someone can help me with some solid experience, or tell me that consulting firms should stop giving way to clients and force them to pay for more time and resources. Or maybe someone will tell me to pick a different BPM tool that makes analysis, implementation and deployment so easy that the missing link was in fact a natural and necessary part of software evolution.

Comments welcome!

A post from the Improving It blog

Download the podcast of this blog post

Your 'Systems Group' is the reason you business teams (are) disintegrated

phil_ayres@hotmail.com (Phil Ayres) — Sun, 14 Jun 2009 18:16:20 PDT

One of the big selling points of business process management (BPM) is the way it can provide order to the activities of disparate groups of workers so they can work better and more efficiently. To achieve this, you have to answer the big question 'how did groups that have to work together so closely end up so separated?'. In parts of a businesses that handle customer requests and new accounts (such as insurance underwriting or claims, banking account management, credit card disputes, telco and utilities customer service), it is typical to see separate systems forcing the business groups apart. When groups of users have to operate systems that don't work the same, don't share data and require swivel-chair integration, the way they work together as teams disintegrates.

It is the 'Systems Group' (or groups with other vague technical-ish names) that runs the line of business systems. And it is these owners that perpetuate the separation of business teams by failing to integrate their systems. So it seems obvious where to place the blame - the 'Systems Group'. But it is not their fault.

Repeated observation has shown me that the systems group are experts in what they do: they understand their systems better than anyone. They understand how the systems work, how to keep them working, and how to work around their faults. Because of this they are also often the designers of new 'applications' that fill a need of the business, in the form of Access databases or enormous Excel macros, that further separate and distinguish the roles of individual business users. And they are rarely experts in integration, largely due to the time and patience they must expend on nursing their current systems through another painful situation.

I have a recent example on a project I was leading - I had to teach various highly experienced technical people in the system group about XML, what it was, what it looked like, why it was different from EDI, and how a BPM system could use it to capture data from other systems (including that big Excel spreadsheet that is core to the business). XML is really not that new a concept or technology, but the guys had not had the opportunity to understand it.

With a limited knowledge of the available technologies, and even more limited time to burn, an organization's 'systems group' is not the team to apply to even basic integration tasks. If it was, the integration would have been done already.

So who should do targeted integration associated with BPM projects? That consulting team you have onsite already to build the new BPM solution may cost more than your internal team per hour, and may not be pure software developers, but it is likely that they understand integration mechanisms better than most. And if they represent a decent boutique firm, even if they can't build the integrations themselves they should have access to a team that can. Although it may cost a little more overall, the integration will get done, which is more than can be said for the situation many companies find themselves in currently.

The 'Systems Group' is the reason that your business teams (are) disintegrated. But it is not their fault. So help them improve, the same as you are trying to do with your business processes.

A post from the Improving It blog

Download the podcast of this blog post

Stop Persevering, Start Thinking

phil_ayres@hotmail.com (Phil Ayres) — Sun, 14 Jun 2009 18:15:58 PDT

Consulting and software projects do funny things to incredibly smart people - they make them dumb and irrational. I've experienced it first hand (though I don't admit in public that I rate as incredibly smart).

So what's the deal? We've all used some variation of the phrase 'you can't see the wood for the trees'. That's what tough projects can do to people. They get so involved in the details of the project that they either don't notice that the project is starting to fall apart, or don't notice that it was never really together enough in the first place to fall apart. Then disaster strikes - the shit hits the fan - the customer starts ranting (more than before) and the incredibly smart people fall into the worst trap possible; they keep doing what they were doing before, just now at nights and weekends.

There are only three people or roles of people that I think can help prevent, or at least fix this when it happens:

1) The project manager or leader - the person who is falling into the trap and taking the project with them

2) The project manager's boss, mentor, or someone close to the project - preferably someone the leader trusts

3) The client - the guy who is being the biggest pain in the ass that there is right now

As a project manager, how do you prevent this? Well, I don't know that you can, but try following your own rules maybe and put in some checks or balances for your own personal behaviour, independent of the project.

How many hours have you worked this week? Is it significantly greater than the average project you run?
Have you started to find excuses why you can't do things differently in the project (the client will say no to everything you suggest, its just impossible, etc)?
Have you made your team members miss personal events, weekends, etc?

As a project manager, when you really feel you can't take an hour off, do just that. In fact take two. One hour, complain and moan to yourself, go for a walk, do something that forces you to get away from the PC. The second hour, start brainstorming about how you can change the project; what is the stuff that is unnecessary, what can you do differently. This is brainstorming. Nothing is impossible. You can work out in the third hour (three hours, impossible!) what is going to be most effective at getting back on track with minimal impact to the value of the project.

As the person the leader trusts, have you seen this issue getting bigger? How can you help? I'm no counsellor in this stuff, and have always enrolled in courses of 'tough love'. Painful for everyone involved, unfortunately, though often gets the job done. Help the leader brainstorm, and visualize where the value in the project comes from, which is often not the individual details. Help them understand how they might sell some of the changes to the client.

Then there's the client. Why in the world would you want to put your project at risk, along with the potential risk to your business and credibility? So maybe its time to start compromising a little. Screwing the vendor or consultant out of every last bullet point rushed into the last draft of the contract or scope may just lead to a valuable, expert team becoming so overwhelmed that your aim of getting the perfect system may result in you getting nothing. Or worse still, a vendor that provides a system that looks great until its put into practice (cos those little features and design points you bullied them into were actually meaningless or of minimal value). Finally you could end up with a system that is functional, but nobody wants to go near it, in-house or external, because its tainted with bad-project vibe.

So, when you find that you just need to persevere a little more (beyond the 70 hours a week you already are), or need to shout at the vendor beyond the point that its fair sport, its possibly time to stop, put down your tools, and do the hardest thing of all. Start thinking about what you can change, and what you can ask the client or vendor to be changed, to get the project back on track.

A post from the Improving It blog

Download the podcast of this blog post

Custom software development is really better than complex configuration?

phil_ayres@hotmail.com (Phil Ayres) — Sun, 10 May 2009 19:44:13 PDT

Another week in Mexico City, and nothing chaotic or remotely strange (by Mexico standards) happened. Life is heading back to its usual modus operandi. Offices have thermal imaging cameras at their entrances to catch suspected flu carriers, but traffic on the streets is back to its chaotic self and everyone is happy that this signifies a return to normality.

As for my current project with the large multinational insurance company, things are getting interesting. The team has entered an iterative 'construction and validation' series of development 'sprints'. The Case360 product is doing exactly what it should: providing a flexible platform for rapid development of process and document management solutions. Its nice to know that the messaging I put around it from a product management and marketing perspective while in the company was really true! I have to hope that Global 360 manage to keep some level of focus on the product in the future, since it really is a great technology.

Some interesting facets of using a product of this type, which allows production solutions to be configured without coding (beyond a little script here and there), are:

(a) how fast you can put skeleton solutions together that you refine over a series of iterations

(b) what a waste of time documenting and formally designing a solution can be

The power of a software product that allows configuration of meaningful solutions, based on its templates and best-practices, also carries some risks. The major one is (c). A deep understanding of what the product offers, and how all the available pieces fit together in a usable and maintainable way is required by the consultants doing the work. Otherwise the solution becomes a series of disconnected and confusing components for the end user to navigate (how many of you remember Lotus Notes applications?). And some complex requirements, though possible to meet, require some serious thought, prototyping, rework, and occasionally coding, that can be hard for a customer to comprehend.

Its strange to me that customers are often willing to accept the opaque nature of custom software development if the whole solution is based on this. But if a solution is largely configuration and clever reuse of templates, anything complex is looked at with contempt, even though that the final solution is far more manageable than most custom software. There's no pleasing some people!

A post from the Improving It blog

Trust is key in software projects

phil_ayres@hotmail.com (Phil Ayres) — Tue, 05 May 2009 09:40:43 PDT

Building relationships with customers based on trust is difficult. When you are providing your customer services, rather than tangible deliverables upfront, this becomes even harder. Trust is essential in software projects of any style, since it absolutely will affect the perception and success of any deliverable. I don't proclaim to be an expert in the software services business, though I have run several large software implementation projects, while being involved in numerous others from the sidelines.

Right now, I'm running a business process management (BPM) and document management implementation for a global insurance company in Mexico City, while being involved in a technical consultant sideline role for the same company in Chile. If I had been the customer I might have chosen to stagger the implementations to make best use of the reusable components and experience, but the reality of budgets and timelines does not always allow. Either way, we have two projects running simultaneous, for the same parent company in different countries, following very different implementation styles:

Chile - traditional (waterfall) model: analysis, design, development, testing, rollout

Mexico - a modified scrum: iterative analysis and development with iterative timeboxed deliverables, final testing, rollout

The challenge from either approach is proving to be building the trust of customer early enough in the project to set out on the right track for the style of project you want to run. So here is what I'm seeing.

Large insurance companies continue to be conservative in nature, meaning that a traditional software development cycle is something they are familiar with and comfortable with. The problem is that the trap becomes paralysis through analysis. The development of the solution may never get started, because it is impossible to get the customer to agree on the scoping and initial analysis. In this case, I can't tell whether the design will deliver what the customer really needs, as they have no experience with the best practices or limitations of the tools they are building on. Within a reasonably well defined timescale they are going to get a set of applications that work according to the design. Trust in this environment has come from extremely tight scoping and analysis sign-off, and will hopefully build into a more flexible trust soon.

Taking another approach, I've been working on my customer to move them to a more iterative project. This has been uncomfortable for them, as they feel that they want to know what they will get before agreeing to the scope of the project. There are items they are clinging onto strongly that I would bet a fresh fish taco on that will be dropped (or at least significantly diluted) by the end of the development as they understand what these requirements mean in reality. The challenge here has been building enough trust between client and consultants early in the project that they will get a usable deliverable in their timeline. Perfection has never been promised, and there continues the risk that the scope which forms the contract is open to interpretation. The deal here rests on a combination of personal trust and constant expectation setting, aligned with a flexibility within a restrictive scope.

Which project will work best is yet to be seen. Chile has the best chance of meeting the customers initial requirements most closely, but has the equal risk that these requirements will not provide the full value that could be envisioned, requiring a further deep iteration. Mexico has the best chance of being delivered to time and budget, though with many gaps that the customer will return to in a second phase. Similar result, we'll see which gets closest in expectations met, time and budget.

My belief right now is that the iterative approach is a good fit for the tool we are using, and a loose BPM methodology. I'll be letting you know whether this was a good bet or not!

A post from the Improving It blog

Business continuity: how will your company cope?

phil_ayres@hotmail.com (Phil Ayres) — Tue, 28 Apr 2009 19:20:24 PDT

I'm in Mexico City working on what could be (could have been?) a fun and challenging 3 month project, implementing business process management (BPM) and document management in a global insurance company. Now the city is faced with being the source of a potential pandemic of swine flu. This is giving me first hand experience of how companies handle business continuity planning (BCP) in different countries. And I'm reminded once again that, business continuity is not about having a bunch of backup tapes.

My earlier experiences with business continuity planning were working for a vendor of Imaging and Workflow in the UK, in the government and insurance sectors. Customers of any size believed that if they were going to implement such technologies to improve their business processes they would probably become dependent on them. They also seemed to buy the concept that if you were going to improve your business processes, you should take the opportunity to improve the security of your information and the resilience of your operations.

The whole concept of business continuity was reinforced to me with a very powerful punch one day when I was helping a large systems integrator to design a system for the UK government, to support around 6000 concurrent users. Not only were we discussing the value of near real-time backups to offsite locations, but added to that the logistics around providing a system to test business continuity. The testing would involve not just taking a server and unplugging it to test failover to a secondary system, but would also test how the plans for moving a set of essential users to a temporary location would operate, both technically and logistically.

Then the first of many amazing calls came in. The day was September 11th. We all know what happened next. Less obviously, the business continuity procedures of hundreds, if not thousands of companies were tested. There are many examples of those that worked and those that didn't. Some companies managed successfully to move their entire financial or trading operations overseas and absorb the increase in load for the remote resources with seemingly minimal effort. Other companies just vanished along with their information, their infrastructure and, extremely sadly, the knowledge in the heads of some of their key workers. Since those days, companies have learned their lessons, and some have unfortunately forgotten them.

I moved to the US in late 2003 to work in the same imaging and workflow business with the same profile of organizations. I was shocked at how little attention US companies and government paid to providing more than a bunch of backup tapes for business continuity. In the event of an office flooding, being struck by lightening, or something more catastrophic, these organizations would not only have to rebuild their complex servers from the ground up, they have to restore terabytes of information from tape, and procure PCs and temporary office space for their workers. Weeks of time, and in the case of the commercial organizations, hundreds of customers would be lost. In my opinion, US companies seemed unwilling to invest to mitigate risks such as these. Since some of those organizations are / were around the Gulf coast, I hope they are still around to tell the tale.

Things have changed at least from a remote infrastructure standpoint. Companies have the advantage that most of their professional workers, even here in Mexico City, own a PC and a broadband Internet connection. The infrastructure of temporary office space may be unnecessary. And I have watched many companies making the most of that today with the current flu situation, as they try to reduce the number of groups of people in close proximity. In the pair of office tower I work in, Torre de Esmeralda, an estimated 40% of people were working from home. The question is, if the minor tremor of yesterday had been more than 5.6, how many would have had adequate, ready to roll offsite servers and information available for those users, or others in a completely different city?

Business continuity planning, the technology of resilient business process management and document management, and the logistics to make it worth anything, is being brought back to the attention of companies worldwide.

A post from the Improving It blog

Mexico City - up front and personal

phil_ayres@hotmail.com (Phil Ayres) — Sat, 25 Apr 2009 14:52:03 PDT

What an interesting time to be in Mexico City. Watching the inhabitants of this enormous city's response to what could turn out to be an incredibly nasty situation has been an education in the culture of the Mexican people. Watching how the government and companies are addressing the situation as well has also been interesting.

I've only been in Mexico for 7 days, which means that I had been here about 3 days when the news about the first cases started to be recognized as meaningful. Listening to the discussions about the issue in the office where I am working (a multinational insurance company) has been enlightening.

Day one of the news (at least the first day I was aware of it), people were joking around about about having the flu every time someone sneezed.

Day two, the company was distributing blue face-masks to everyone in the office, the doors were opened to ensure air circulation, and presumably the air-conditioning (if there really is any, as it always feels tropical) was turned down. People continued to joke about the flu, though the habitual greeting kiss was avoided as recommended by the government. Maybe 75% of the office population had their face masks on, both inside and outside the building. Given the speed that the face masks appeared, I wonder if they were kept in storage by the company for this eventuality. Business continuity planning at its finest.

Day three, and people seemed to be getting tired of the face masks. Those who had been wearing them, kept them round their necks, and I'm not sure if this was as a symbolic protective chalice, as a safety net in case they spotted someone who was sickly looking in their vicinity, or because they had not quite reached the stage where they had the confidence to take it off completely however much it was annoying them. Schools, universities and government institutions are shut. Hospitals and health centers are open 24/7. Keeping people apart in this crowded city is a tough proposition.

Day four. I'm not in the office as its a Saturday. A large handful of people are walking around the city wearing face masks, but I'd say the majority are not. The civil defense troops have been out in some parts of the city distributing face masks, and the metro is also handing them out. Unfortunately, I don't see the taco stand cooks wearing them, and I bet no one in the restaurant kitchens is. Maybe tonight would be a good night to stay in and cook!

The people of Mexico City seem to have taken this worrying situation in their stride, showing their typical relaxed, courteous (unless they're driving) and humorous character. The government has rolled its health plans into action quickly, calmly and without fuss, which is probably a good thing, as a city of 23 million inhabitants panicking could lead to more of a disaster than the potential spread of this nasty virus. The good thing is that people still seem to be getting on with their lives (based on the level of traffic outside my window).

Fingers crossed that the number show a positive decrease in cases over the weekend.

A post from the Improving It blog

Twitter... And back again...

phil_ayres@hotmail.com (Phil Ayres) — Tue, 14 Apr 2009 14:11:48 PDT

Back in January I announced I was not going to blog any more, instead diverting my creative juices to Twitter. Well, there is only so much that can be said in 140 characters, so I've decided to make a trial comeback. To try and refresh the blog a little there is no big makeover, just a change in name. For the astute, you'll see the name changed from "Improving New Account Opening" to "Improving It". I wanted to give myself some latitude in what I could write about, while not scrapping the great (and mostly relevant) content that is already in the blog.

So for my relaunch, welcome (back) to Improving It. In this blog I'd like to have a conversation with anyone that stops by. If you are interested in technology for solving complex business, social or economic problems, remember to click the RSS, Twitter or Email links in the side menu, and I'll be there ready and waiting in your feedreader, inbox or Twitter. Or just stop by this site.

I'm going to try very hard to make this a conversation, so please comment, trackback, tweet or whatever technology you use. If I see you link me, I'm more likely to read whatever you are writing about. If its good stuff, I'll probably return the favor. As such, its time for a clean slate, so the blogroll / links will be cleared out to make room for current exciting stuff.

Enough of the admin, I look forward to chatting with you all soon about technology, business, the economy, the environment and whatever else takes our fancy!

A post from the Improving It blog

Changing to Twitter

phil_ayres@hotmail.com (Phil Ayres) — Mon, 12 Jan 2009 08:31:57 PST

Microblogging is apparently THE way to communicate and share discussions. Twitter, really little more than a central site for publishing and tracking SMS-style messages, is the great enabler in this. So if you are as tired of reading huge long blog posts as it seems I am of writing them, feel free to follow me on Twitter: http://twitter.com/improvingit

The name change is there as I'd like to broaden my discussions. My work world for a while was finserv solutions and pure IT. In blogging, I realized there is a lot more that interests me to chat about, so Improving It (or IT) gives me a little more freedom to discuss the issues that affect all of us in business and life - from technology, IT and green issues, to the whole human race just getting-along. And I hope that Twitter makes the discussion a lot more interactive (its hard to write an uninteractive diatribe in 160 characters).

I may post here from time to time, though I'd really like it if you chose to follow me on Twitter and join the disussion. The RSS feed is linked at the bottom of this page: http://twitter.com/improvingit

Thanks for reading and I hope you can follow me on Twitter!

A post from the Improving New Account Opening blog

The history of workflow and BPM

phil_ayres@hotmail.com (Phil Ayres) — Tue, 02 Dec 2008 06:15:58 PST

Congratulations to everyone in the States that survived 'death by turkey-sandwich' over Thanksgiving, and hopefully managed to spare just a moment to remember the meaning of the long weekend. Unlike Independence Day (where I just get jokes about how the Americans threw the English out, and my jokily sarcastic replies fall flat), I can buy into Thanksgiving.

Serious stuff over, its back to work now. My Monday was spent turning over a new leaf and making sure I get my head out of the tasks I'm doing long enough to look around and see what else is going on out there. I find that anything involving really using software (I've been building some demos with the sales engineers using Global 360's case management software) can quickly pull me down into the weeds of 'doing it right' rather than 'getting it done'. Anyone that has worked around Sales knows that the deadlines rarely let you really do anything 100%, so this can be a challenge for me.

In looking around, I came across this nice morning coffee post by a guy I hadn't read before, Arshad Nazim. In it he writes about the brief history of BPM, and in doing so I think answers the question that many long-time software people have when they first see BPM: 'what's the difference between BPM and workflow?'. Not mine to answer, but I think that Arshad does a good job of doing so. [Note: it seems the credit should go elsewhere, since Arshad forgot to credit Sandy Kemsley who wrote the whole series series A Short History of BPM, which was a pleasure to re-read in its original format on her Column 2 blog. I've moved the link to Arshad's post to here, so that readers can review the additions Arshad made subsequently].

I'm looking forward to starting to write more regularly again, so keep an eye out for my next 'original' post.

A post from the Improving New Account Opening blog

Oracle buys into Business Rules Management?

phil_ayres@hotmail.com (Phil Ayres) — Wed, 29 Oct 2008 21:20:50 PDT

Oracle announced today that it acquired RuleBurst Holdings, the parent company of Haley, providing what is described as policy modeling and automation software. Carole-Ann on the EDM blog talks a little about Haley's focus, which she says is more about natural language rules than the structured business rules definitions that I'm more familiar with.

Either way, its interesting that Oracle is currently saying that it intends to match Haley with its ERP and (Siebel) CRM products. I can certainly understand the rationale for this, matching compliance policies to core systems makes a lot of sense, enabling best practices to be enforced at the heart of the business. I wonder whether Oracle have thought much about embedding Hayley into the Oracle BPM Suite as well, since there seems to be a fairly natural match.

Like all rules systems, Haley probably offers more value from being a centralized service than being limited to automated business processes, so strict embedding probably doesn't offer Oracle BPM much more than marketing spin and analyst kudos (both important obviously). In practice customers really want their rules to be used by any process, system or application, so loose integration is likely to be acceptable.

With this, the number of independent rules vendors has shrunk a little further, with IBM already having acquired Ilog and SAP acquiring Yasu (according to James Taylor on the EDM blog - I had missed this news). So HP and its growing software division will probably need to snap someone up just to join the party, and EMC will need to work out whether its partnership offering of Corticon is appropriately profitable before making a move into owning its own technology. Microsoft must have a play in here somewhere as well, though it seems to be happy with the Business Process Alliance as a provider of best of breed process and rules technologies, at least for now.

Where does this leave independent BPM vendors? Owning rules technology outright is appealing for the marketing and analyst reasons stated above, but are business rules management systems owned by BPM vendors appealing to customers when they plan to deploy them as centralized services? As rules become just another capability of company ERP systems, maybe the push will be for BPM software to provide clean integrations to these new ERP rules engines, much as content management software often leverages the storage and full-text search capabilities of the database. Time, and a some heavy IBM/Oracle/SAP marketing will probably tell.

A post from the Improving New Account Opening blog

Finovate in NYC

phil_ayres@hotmail.com (Phil Ayres) — Fri, 10 Oct 2008 14:58:02 PDT

I was hoping to take a visit to the Finovate event in NYC next week, to see some of the hot new innovative financial services products and software coming out of the industry.

Unfortunately my travel schedule seems to be as unreliable as the markets right now, meaning that I can't attend. So I'd like to wish the organizers and companies that are presentering the best of luck for the event and I look forward to seeing some feedback from some of the bloggers and media who'll be onsite.

A post from the Improving New Account Opening blog

Processes in the cloud

phil_ayres@hotmail.com (Phil Ayres) — Wed, 01 Oct 2008 19:42:32 PDT

Amazon, in its new incarnation as cloud computing provider, has announced that its EC2 service will have the ability to run Microsoft Windows Server or SQL Server before the end of the year. Why does this matter?

Companies are under pressure to deliver applications for a better total cost of ownership than ever. This isn't just a matter of cheaper software and less sys admins to support it. Already we see the importance of virtualization, helping reduce the cost and increase the flexibility of corporate server rooms, at least for the products that certify themselves to run under products such as VMWare. Side this with the new 'green' push of Intel, AMD, Sun, etc - to show a reduced cost of electricity powering and cooling the masses of servers that are still required, and the complexity of organizing server rooms to do so. According to Sun, 25% of IT budgets is consumed by energy costs.

So why not just save the valuable office space that server rooms have expanded to overtake, the power costs, complex network wiring, and the cost and risk of knowing how to, and actually doing this infrastructure stuff well? Just deploy your applications to the 'cloud', make sure you have a powerful and fault-tolerant Internet connection, and away you go.

Does this work for your critical business processes, perhaps run by a business process management (BPM), enterprise content management (ECM) or traditional imaging and workflow solution? AIIM talks about SaaS for ECM, and adds some nice commentary on the key tests for an organization selecting a SaaS solution: does SaaS meet the tests of speed, functionality, cost, flexibility and suitability?

Since BPM should be about running your differentiated processes, the cookie cutter approach to cost effective SaaS solutions may not be appealing. But when you have the ability to build exactly your solution and run it in the cloud on a common Windows operating system and database, BPM might become viable without complex infrastructure requirements (at least those that your boss can see).

A post from the Improving New Account Opening blog

Thick or thin for heads-down workers

phil_ayres@hotmail.com (Phil Ayres) — Wed, 24 Sep 2008 19:33:42 PDT

Thick or thin, that is the question. At least for 'heads-down' workers typically involved with processing large amounts of information on screen extremely rapidly, thick client applications have long been considered the only way to go.

Proponents of thick clients used to argue for the richness of UI that could be presented, but I feel that modern browser based apps on the web show that this doesn't have to be the way. I'm sure you have your favorites you use every day.

So it comes back to performance - speed of refreshing the screen and displaying information. Heads-down users need the applications to work fast, update dynamic data rapidly, display document images in sub-second times, so that their boss can benefit from an aggregate of 'per-click' savings. Thick client-server apps claim the gold standard here.

Can dynamic AJAX applications really keep up? After all, the limitation here becomes the latency of the network. Can browser applications compete with the thick client running on an over-inflated PC generating dynamic displays from data cached ahead of time? Unlikely, as the thick client probably wins every time, pulling data behind the scenes in large chunks.

So, can we really say that browser based UIs are suitable for heads down workers, or are they just more convenient for IT in not having to roll out complex installable applications? Or are browser based apps up to the task? After all modern networks are fast, clever data caching can be built in, and new Javascript engines are claiming to get orders of magnitude faster.

Silverlight and Flash are battling for the new rich Internet application space. I question whether they just provide a nice toolset for building highly dynamic application UIs that roll out easily, or can they really provide a higher performance operation? Don't get me wrong, anything that speeds the design and deployment of applications is a good thing, but when they are really a nice skin on Internet technology, can they offer the performance of a true thick app?

When the standard heads-down applications typically are plain, keyboard driven, frankly having little glitz or glamour, is there a place for rich Internet application technologies? Or will software vendors just adopt them as a sales tool, to out-pretty the other guys.

A post from the Improving New Account Opening blog

Do you trust this blog?

phil_ayres@hotmail.com (Phil Ayres) — Mon, 15 Sep 2008 20:00:30 PDT

As most educated users of the Web know, there is a lot of misinformation, speculation and lies out there. So who better to trust on the future approaches to help users identify trustworthy sources of information than the inventor of the World Wide Web, Sir Tim Berners-Lee. Reported on the BBC News website, Sir Tim discussed a range of issues facing the Web, as he publicized the creation of the World Wide Web Foundation.

Interestingly, the issues faced by consumers outside the firewall should be concerns for organizations deploying web style collaborative and social tools inside the firewall. In a small organization, my job title and personal contacts are usually enough to generate trust that the information I post on a Sharepoint site or blog is authoritative and can be used appropriately. People know me, or at least know of me, and trust that my role in the organization can help answer a question they have accurately.

In a large organization, as with the Web, reputation is harder to ascertain. Toby Bell at Gartner talks about reputation from many angles, often with the view that reputation can only come from the aggregation of everything you write and link to, as well as your closest contacts. This doesn't give me a view of someone new at a glance though, which is one of the issues that Berners-Lee would like to see addressed, since how many of us have time to read enough to really assess a person's authority.

I'm sure that there is no easy answer to this issue. Much as Wikipedia tries hard to separate truth from fiction, organizations need to be sure that formally published policies, procedures and compliance documents are instantly recognizable and clearly segregated from more democratically published information, however authoritative the author may be. For CYA that seems to be a defensible approach.

I strongly believe in the value of collaborative technologies. I don't know that they will change the world, but certainly as more of us try to travel less, their use will grow, and the risks of 'wild wild web' need to be understood to ensure we all realize their value.

A post from the Improving New Account Opening blog

SharePoint for Production Applications?

phil_ayres@hotmail.com (Phil Ayres) — Tue, 09 Sep 2008 06:19:45 PDT

First, imagine you run a claims department for a large insurance company, or the customer service center for a top-tier bank. Then imagine the many line of business and information systems your employees use every hour of every day to get their jobs done. Finally, consider how much better their productivity and job satisfaction could be if all of the information and resources they needed were presented within a single application environment. No more carpal tunnel syndrome inducing Alt-Tab maneuvers, mornings spent carefully arranging application windows in that early Windows style, or lengthy (dull) training on several very different applications.

I have spoken to many the leaders in many organizations, run by people that you are currently imagining you are, who have recognized the appeal of bringing together all the applications their people use into one place. The approaches that are taken vary, depending on the exact need, and which software industry analyst makes the most compelling pitch. Anything is possible, including enterprise portals, 'roll your own' SOA/EAI applications, consolidation to a single platform in the SAP R/3 style, and presentation with the line of custom applications built on document management and business process management suites. And without naming names, there are many examples of the different approaches becoming extremely successful, or becoming another annoying window on an already overcrowded screen.

SharePoint, accompanied by its enormous marketing budget can't fail to make it into the departments you are imagining you run. Its appeal of being cheap, easy and 'good enough' makes it an important option to be considered. So, ask yourself this:

Does SharePoint offer enough value as a pretty configurable presentation mechanism / portal to make up for the fact that (in my experience) its just painfully slow to use?
Does it provide the integrations you need with the many core systems and information systems you have in place to plug and play (how many BizTalk skills do you have in house)?
Do the Web 2.0 style, collaborative team space capabilities of SharePoint provide application components that truly benefit your workers?
Does your organization need another application layer of 'can do lots of stuff' that pays little attention to the value it offers to the business?

In some cases, the business leaders I have met could answer 'yes' to all of the above, and are starting to try out SharePoint in their environments. In other cases, other business leaders actually have a vision to address the root cause of the mosaic of applications their employees endure. They have asked themselves a different set of questions:

Is there a way to show users just the information they need within the context of a single business application, not a series of segregated application portlets or panels?
Is there a solution that can deliver work and guide users to complete the tasks I know need to be done, rather than having to train them to always remember what must be done next?
Can the skilled knowledge workers have the flexibility to do what they need to do, without being limited by a production line workflow?
Is there a solution that can provide the best of both worlds - a targeted business solution and a flexible platform which allows me to adapt to a changing business environment?

I personally don't think that there is any one answer. As the imagined business leader, you'll be balancing an operations/IT budget against a need to deliver business value in the shortest amount of time. Some organizations will make use of SharePoint where it fits their needs best. Others will try and force fit it into applications it doesn't do well.

As the business leader, I think you have an easy question to ask yourself. Does a software solution help you meet the objectives of the business (increase revenue, reduce expenditure, etc) with the better working practices that it offers, or alternatively just provide an attractive UI and collaboration functionality around your current working practices?

A post from the Improving New Account Opening blog

Privacy or personal responsibility?

phil_ayres@hotmail.com (Phil Ayres) — Wed, 27 Aug 2008 18:58:57 PDT

Privacy of your personal information seems to be almost as hot a topic in Europe as the price of gas is in the States. Much like tax on petrol in Europe seems to be the cost of doing business, anything less than identity theft seems to be acceptable here in the US.

The fact that there has been yet another lost PC, USB drive, backup tape, or whatever, with tens of thousands of records of personal information on it is worrying. Cloak and dagger stories aside, the fact that these are routinely linked to the security services or the company contracted to provide secure ID cards for every UK citizen, big brother is failing (or not, depending on who picks up that information, says the cynic in me).

I work with government agencies and financial services companies who routinely are subject to their own internal security audits and ethical hacker test scenarios. And like anything with a moving target, sometimes they miss. Fortunately I will say, I work for a company that takes this very seriously - in line maybe to preventing production data loss from a software 'glitch'.

The problem is that individuals aren't held equally responsible. Catching up on a few days of many weeks of missed blogs, I ran across this one, A true, global Big Brother case. The story here is how trackable you become when you use a Bluetooth headset, and you don't take the responsibility to understand that it being in range of some other device that can 'discover' it, means that you can effectively be tracked as you move from place to place.

Should you have to care? Probably not. But I'd hate to see another mandatory warning having to be put in the oversized headset box, when perhaps the software that helps you set this thing up could warn you of the risks that naming the device with your phone number or name makes you identifiable - your risk, choose to be stupid if you want to. Of course, the phone you are carrying with it, with the SIM card, GPS, and so on leave you pretty open anyway, just more anonymously.

Privacy, or having your movements tracked anonymously at least, could be nothing to be feared, as long as you don't put yourself in a position where the use of the tracked device could incriminate you. Being concerned about big brother is reasonable, but worrying about it may only be for those with a guilty concience.

Am I concerned about having big brother track my movements? Of course, but Google does so virtually with every online step. There is, it seems, no escape!

A post from the Improving New Account Opening blog

Relaunch?!!

phil_ayres@hotmail.com (Phil Ayres) — Tue, 26 Aug 2008 14:36:55 PDT

I've considered getting back into blogging more frequently. The last post was end of last year, so it shouldn't be hard to do just a little better. I considered starting a whole new blog, with a new name, new style and so on, though that represents a large barrier to (re)entry, so I'll just jump right in. The biggest change will be that I'm going to try and write short, sharp and maybe

Over the next few weeks, you can expect me to write about my opinions on the trends in technology, business solutions, social networking, ECM, BPM, SOA and maybe the occasional unrelated rant as well. As ever, the thoughts, expressions and opinions are mine and mine only, so no blame should be aimed at my employer. And if you work for competitor, you are welcome to read this blog, but don't expect to find any insight into the intellectual property of Global 360!

I'm looking forward to posting and hearing your comments too!

-- Phil

A post from the Improving New Account Opening blog