Skip to content

{ Category Archives } Forrester

Untamed business processes #BTF09

You know that you’re getting near the end of a conference when the number of people on the panel is almost as many as the number in the audience. The last session of the day is a breakout, and I attended a panel with Craig Le Clair, Chip Gliedman and a third analyst (George) who was substituted in for Paul Hamerman, but for some reason they had not spent the necessary 10 seconds to update the title slide.

They classify processes into “tamed”, meaning those that are so structured, they’re embedded within packaged applications such as ERP and CRM; and “untamed”, including everything else, including all those processes that we implement in BPMS. I’m not sure that I agree that some of their untamed processes are not structured; rather, a packaged app doesn’t provide the right degree of flexibility, or the market for the process is small enough that there isn’t a packaged app to deal with that process.

Forrester has an interesting format for this type of panel, where each of the analysts takes on a persona and a set of opinions that I don’t think necessarily represents their own opinions: although I like the light-hearted back and forth conversational manner, this has too much of the air of a high school debate club where anyone can argue any side as required rather than analysts who actually hold opinions on this subjects. I found this one to be too distracting to focus on the content.

That’s it for the Forrester Business Technology Forum; all in all, a lot of great content in a fast-paced two days. There could have been more on Lean business process improvement rather than Lean software process improvement, especially considering that half of the vendors in the showcase were BPMS vendors, but I still gained a lot of value from the conference.

2009 10 09 Sandy Kemsley Comments (3)

Social media and business activity monitoring #BTF09

James Kobielus and Natalie Petouhoff presented at a breakout session on social media as a method for gaining visibility into your customer service processes: customers will react on social media channels such as Twitter, Facebook, review and community sites, and blogs if they have either a good or bad customer service experience. I’m not sure that this fits into the classic definition of BAM, but it does provide insight into how well you’re working with your customers.

They referred to the “witness factor” that social media has on business transformation: if people within the company know that they are being watched and commented upon, they often change their behavior in order to make those comments more favorable. Social media provides one window for a company into their customers’ impressions of the company and products; since people are much more likely to comment if they have a bad experience than a good one, those are overwhelmingly negative, but still represent valid complaints.

One problem with many current BAM applications is that they’re trapped within a BPMS framework, and are focused primarily on the data and events generated by that BPMS. Instead, we need to move towards a more comprehensive monitoring environment that can accept information from a number of different sources, including social media channels. Just think of tweets as events that can feed into a monitoring dashboard, allowing a customer service representative to review and respond to those in the context of any other customer-related events and information. Kobielus mentioned that there is little integration of social media into traditional BAM tools, but I think that we’ll see this sort of functionality being offered by other tools, such as more forward-thinking CRM.

This seemed to be a bit of a disjointed presentation, with social media on one side and BAM on the other, but there are ways to bring this together: in advance of this session, I started a discussion with my fellow Enterprise Irregulars about Twitter being used for customer engagement (not just one-way PR blasts), which has resulted in a fascinating stream of messages that weave around these same issues. After I’ve had a chance to digest those a bit more, and think about how this impacts on business processes, I’ll bring some of those ideas forward.

2009 10 09 Sandy Kemsley BAM Comments (1)

Lean application development strategies #BTF09

Dan Carmel from SpringCM gave the second keynote today, focused on his premise that SaaS = Lean. Although I would agree that many SaaS applications are Lean from a customer’s standpoint, that’s not true with all of them. Yes, using SaaS applications potentially has a much leaner footprint for a customer since there is no hardware or software on their own site, but you also need to consider the efforts to integrate with other systems, including on-premise systems. If the SaaS app (or any on-premise app, for that matter) can be reconfigured and integrated with a minimal effort, then things continue to look Lean; if it’s closed and requires custom kludges to integrate, then not so much.

He went through some good examples of Lean and extensible SaaS environments, such as Salesforce.com and Webex Connect, then pointed out some areas where on-premise systems can be a big challenge, but SaaS can provide sufficient business value even at lower volumes: ECM, for example (no surprise, since that’s what SpringCM sells), where high initial costs tend to keep all but large companies from deploying internally.

He then introduced Joe Graves of Stratus Technologies (a SpringCM customer) about their journey with SaaS. They started using Salesforce.com about five years ago, deploying to 170 users worldwide in a matter of weeks from the start of the project. They use a number of applications integrated with Salesforce.com, and when they needed ECM for contract management, they selected SpringCM because it’s tightly integrated and because they were already sold on the value of SaaS. He outlined their benefits: lower upfront costs with no capital outlay, quicker implementation time, reduced operational issues such as storage management and disaster recovery, and allows IT to focus higher up in the value chain rather that fussing with operational issues that don’t improve competitive differentiation. Although many people have concerns about customization and integration, security, and uptime of SaaS apps, Graves pointed out that there are ways to deal with all of these when you’re working with a properly built app, and that as long as it meets your functional and operational requirements, there isn’t a problem. [As I like to point out to people who use the highly publicized downtime of SaaS apps such as Salesforce.com and Gmail as justification for not using SaaS: your internal systems go down too, it’s just not publicized across the internet; in fact, the level of transparency that a SaaS provider has around their failures can increase customer commitment.]

2009 10 09 Sandy Kemsley cloud Comments (2)

Forge your Lean process improvement game plan #BTF09

After an intro by Mike Gilpin, Clay Richardson gave the first keynote of the second day, focused on Lean process improvement. We were visited by the ghost of BPM past being Michael Hammer and business process reengineering, focused on mass production but forgetting the people; essentially, it became a euphemism for downsizing. The ghost of BPM present, although it has moved beyond that frightening past, is stuffed full of consultants, books, tools and certification programs, to the point of confusion. The ghost of BPM future, however, envisions an empowered front line and engaged customers.

There’s a greater demand for BPM than ever – 66% of those that Forrester surveyed want to do more with BPM – but almost no one has increased budget to implement it. ROI might still be used to sell BPM projects (necessary in these budgetary times), but the final metrics will be business value-based, since ROI doesn’t necessarily measure the actual business improvement.

Lean is shaping the new world of process improvement: processes are moving from standardized to flexible, and the focus is moving from ROI to value since the old IT-centric metrics just don’t work any more. From an implementation standpoint, Lean is about moving from waterfall to Agile, and shifting from on-premise to cloud computing environments.

In order to develop a process improvement game plan, it’s necessary to understand your approach (methodology, tools) and your strategic intent; he had an interesting Lean process improvement (LPI) measure where looking at the correlation between those two factors could diagnose whether an enterprise’s process improvement efforts are bloated, lean or anemic. From there, each of those ranges has a specific plan: if bloated, then you need to connect your process to strategy, and eliminate waste from the BPM technology portfolio (which could mean eliminating some of the tools that you use); if anemic, improve process governance and your process improvement talent pool.

Any process methodology needs to be customized to your specific environment and requirements, and you need to assess gaps in your skills (particularly process analysts) and work towards empowering the business. Process improvement has to be connected to your value drivers, including the center of excellence.

Interesting discussion following between Richardson and Gilpin, especially about BPM mashups (Richardson is just as hot about social BPM as I am): he says that the key to a successful mashup environment that will be used by business people is to make it look like Microsoft Office 2007. He also mentioned that closely pairing a process analyst with the developers can reduce bloat on the project since it reduces the amount of miscommunication across that critical boundary (this, of course, assumes that the process analysts comes from the business side and not part of the development team to begin with).

2009 10 09 Sandy Kemsley BPM Comments (2)

End of the day, on to the evening #BTF09

Jim Haney, CIO of Harley-Davidson, presented on how they’re taking the Lean principles that they already use in manufacturing, and applying to their IT operations. They’re obviously focused on their customers: he started with a picture of a grey-bearded biker in bandana and shades, and pointed out that they do everything for him. :) However, it was the end of the day and I didn’t find the rest of the talk sufficiently compelling to blog about.

Today’s been a bit of a marathon, especially following on the heels of 2-1/2 days at Gartner in Orlando earlier this week, and it’s not over yet: I’m off to the reception on the vendor show floor, then to a special event for women executives to discuss building personal brand, sponsored by Lombardi. Although I’m typically not a big fan of women-only events because I think that they just emphasize the divide, this looks like it will be an interesting panel and I’m looking forward to add in my two cents worth.

2009 10 08 Sandy Kemsley Comments (0)

Designing compelling customer-facing user experiences #BTF09

For the last breakout of the day before the final keynote, I attended Mike Gualtieri’s session on designing customer-facing user interfaces. He started with the idea that application developers have to be involved in user experience design, and not just leave it to the designers (which is, of course, exactly what we did in the bad old days of development when there was no such thing as a user experience designer). Forrester defines user experience as “users’ perceptions of the usefulness, usability, and desirability of a Web application based upon the sum of all their direct and indirect interactions with it”, and propose that a great UX is useful, usable and desirable.

User experience impacts how your customers feel about you, and it’s also not just about the interfaces that the customer works with directly: a second-hand interface can also impact the customer experience, as you know if you’ve ever waited ages while a hotel desk clerk clicks their way through a complex interface in order to check you in. A good UX can increase purchases, retain customers and attract more customers; leaving it to chance hurts your conversion rates, alienates customers and increases your development costs due to redesign and redevelopment.

Gualtieri argues that UX design is Lean (although you could argue that only good UX design is Lean), and sets out best practices for good UX design:

  • Become your users, by listening to their needs, observing them in their natural habitat, creating personas, and empathizing with them. Users typically don’t articulate their needs fully or accurately so it’s not sufficient to just listen to them, but they will demonstrate them if you watch how they do their work. This type of user research is not the same as gathering requirements from business stakeholders; remember the Henry Ford quote: “If I asked people what they wanted, they would have said faster horses”. Forrester uses personas in their own materials – for example, representing an application development manager, complete with picture and name – and I’m seeing some companies such as Global 360 use these for BPMS user interface design.
  • Design first, and understand constraints and potential areas of change as well as the different personas that you discovered in your user research. Keep in mind that you have to serve business goals by serving user goals. Create rough prototypes first, and don’t rush into development or lock into a design too soon. There is some amount of art UX design, so don’t assume that tools can do it for you. Keep the basic principles in mind: useful, usable and desirable.
  • Trust no one: test your designs. It doesn’t matter how many experts review the designs, there is no better review of some features than testing the UX with a range of intended users. Remember that this is not just about usability, it’s also about usefulness and desirability.
  • Inject UX design into your software development life cycle. Everyone on the team should understand why UX design is important, and be incented to help create great UX. UX design should be part of your development process, and requires someone on the team to own the UX design efforts. You still need to use the same techniques as discussed in the other best practices, not just do the design in isolation from the users, but having it integrated into the development team will improve the overall software design.

He finished with the ideas that your development efforts are essentially wasted if the user experience isn’t done right, but it doesn’t have to add a lot of time or money to your project. Good UX design is the mark of a great application development team.

2009 10 08 Sandy Kemsley Software design Comments (0)

Can packaged applications ever be Lean? #BTF09

Chip Gliedman, George Lawrie and John Rymer participated in a panel on packaged applications and Lean.

Rymer argued that packaged apps can never be Lean, since most are locked down, closed engines where the vendor controls the architecture, they’re expensive and difficult to upgrade, they use more functions than customers use, they provide a single general UI for all user personas, and each upgrade includes more crap that you don’t need. I tend to be on his side in this argument about some types of appls (as you might guess about someone who used to write code for a living), although I’m also a fan of buy over build because of that elusive promise of a lower TCO.

Gliedman argued the opposite side, pointing out that you just can’t build the level of functionality that a packaged application provides, and there can be data and integration issues once you abandon the wisdom of a single monolithic system that holds all your data and rules. I tend to agree with respect to functionality, such as process modeling: you really don’t want to build your own graphical process modeler, and the alternative is hacking your own process together using naked BPEL or some table-driven kludge. Custom coding also does not guarantee any sort of flexibility, since many changes may require significant development projects (if you write bad code, that is), rather than a package app that may be more configurable.

It’s never a 100% choice between packaged apps and custom development, however: you will always have some of each, and the key is finding the optimal mix. Lean packaged apps tend to be very fit-to-purpose, but that means that they become more like components or services than apps: I think that the key may be to look at composing apps from these Lean components rather than building Lean from scratch. Of course, that’s just service-oriented architecture, albeit with REST interfaces to SaaS services rather than SOAP interfaces to internal systems.

There are cases where Lean apps are completely sufficient for purpose, and we’re seeing a lot of that in the consumer Web 2.0 space. Consider Gmail as an alternative to an Exchange server (regardless of whether you use Outlook as a desktop client, which you can do with either): less functionality, but for most of us, it’s completely sufficient, and no footprint within an organization. SaaS, however, doesn’t not necessarily mean Lean. Also, there are a lot of Lean principles that can be applied to packaged application deployment, even if the app itself isn’t all that Lean: favoring modular applications; using open source; and using standards-based apps that fit into your architecture. Don’t build everything, just the things that provide your competitive differentiation where you can’t really do what you need in a packaged apps; for those things where you are doing the same all every other company, suck it up and consider a packaged app, even if it’s bulky.

Clearly, Gliedman is either insane or a secret plant from [insert large enterprise vendor name here], and Rymer is an incurable coder who probably has a ponytail tucked into his shirt collar. :) Nonetheless, an entertaining discussion.

2009 10 08 Sandy Kemsley SOA
Software design Comments (5)

How Can Lean Software Enable You To Better Serve The Business? #BTF09

John Rymer and Dave West presented a breakout session in the application development track on how Lean software development practices can be applied in your business. This obviously had a big focus on Agile, and how it can be used within large organizations. Unlike what some people think, Agile isn’t cowboy coding: it is quite disciplined, but it is optimized for delivering the right thing (from a business standpoint) in the minimal time. It’s all based on four principles: deliver the right product, provide hard value, simplify the platform, and allow efficient evolution. An optimal strategy depends on all four of those elements, but Agile projects may deliver on two or three of them, proving the value of Agile before a full Agile strategy is in use.

In order to apply these principles across your entire application development portfolio, you need a strategy that addresses these elements, and provides some way to measure the impact of such a strategy. Delivering the right product requires a focus on people and talent, and the industrial concepts of mass customization rather than mass production; providing hard value requires linking your development process to value streams with their focus on investment return; simplifying the platform requires a focus on tools and technology; and allowing efficient evolution requires optimizing work processes both within development teams and across the organization. I especially liked their chart comparing today’s practices in tools and technologies against Lean practices:

Today’s practices

Lean practices
Install for today and tomorrow Install for today, architect for tomorrow
Configure a general UI for many users Design for people in their work roles
Adopt integrated suites Adopt narrow-purpose modules and services
No component substitution is allowed Component substitution is allowed
Architectural evolution is slow by design Architectural evolution is constant by design

There are ways to bring Agile into an organization, even when budgets are flat and there is the perception that legacy systems just can’t be replaced without yet another huge project expense. Likely, your developers are already practicing some Agile methods already, and you could easily gain permission to prove these out in non-critical systems development.

Good session, with a high-speed tag team between Rymer and West. Unfortunately, the logistics aren’t quite as good as the general sessions: too-small meeting rooms requiring elevator access from the main conference area, no tables and no wifi coverage (at least in the room that I was in at this time).

2009 10 08 Sandy Kemsley Software design Comments (1)

Waterfall contracts and iterative development don’t mix #BTF09

The post title is the best quote from Tom Higgins, CIO of the Territory Insurance Office in Australia, who came all the way from Darwin to speak at both the Gartner and Forrester conferences this week. I had a chance for a chat at the airport with him while waiting for our flight from Orlando to Chicago (and introduced him to the wonder that is the Chicago transit system), and caught his Appian-sponsored lunch presentation today.

TIO is a government-backed insurance operation that covers risks that most insurance companies won’t take on, including workers’ compensation, cyclone damage and other personal and P&C policies. They were looking to reduce their operational costs by making their claims operation more efficient, but also reducing their claims costs by reducing the length of disability claims, which can often be done through proper case management during the period of a claim. Originally the business was set on a COTS (commercial off-the-shelf) claims management system, but when they compared that with BPM, they realized that it met their requirements much better than the COTS systems available due to the ease of use and flexibility. They short-listed three vendors and did a three-day proof of concept with each; that managed to knock one vendor completely out of the running due to the complexity of the implementation, in spite of them being a large and well-respected vendor in the space (no, he didn’t say who; yes, he told me over a beer; and no, I won’t tell you).

For a short presentation, he spent quite a bit of time talking about the contract – including the “waterfall contracts and iterative development don’t mix” line – and I have to agree that this is an incredibly critical part of any BPM project, and very often is handled extremely poorly. The contract needs to focus on risk management, and you can’t let your lawyers force you into a fixed-price contract that has pre-defined waterfall-type milestones in it if you don’t know exactly what you want; in my experience, no BPM project has ever started with the business knowing exactly what they want ahead of time, and I don’t imagine that many do, so don’t mistake a contract for a project plan. If you plan on doing iterative or Agile development, where the requirements are defined gradually as you go along, then a fixed-price contract just won’t work, and will be a higher risk even though many (misinformed) executives believe that fixed price is always lower risk. Going with a time and materials contract requires a much higher level of trust with the vendor, but it will end up as a much lower risk since there won’t be the constant stream of change requests that you typically see with a waterfall contract. Besides, if you can’t trust the vendor, why are you working with them?

TIO had a number of issues pop up during their implementation: the CEO was replaced just before the vendor was engaged, and the business sponsor was replaced in the middle of development; however, due to a strong sponsorship and governance team, they were able to weather these storms. In fact, he sees the strength of the governance team as a critical success factor, along with using your “A team” for implementation, finding a committed vendor and engaging the business early.

He had a really good point about making sure that your project managers is not a business subject matter expert and does use an appropriate project methodology such as Agile. The PM is supposed to be the coordinator and facilitator of the entire project, and not an SME that will dive down the rabbit hole of specific business issues and requirements at the first sign of trouble. I’m a strong believer that PMs should manage projects, not gather requirements, write code or most other activities since that distracts them from the project and increases the risk that it will run off the rails when no one is looking; it’s good to hear that at least one other person shares my opinion on this.

They used Agile project methodology and Spiral development methodology, with six-week code cycles. The team was fairly small: seven TIO team members, an internal business reference group (the SMEs, who eventually became the rollout leads), four Appian people onsite, four offshore Appian team members, and four part-time specialists. The project started with Appian as the technical lead, but that shifted through the first three project phases, and now TIO essentially works on its own with no assistance from Appian. They established a center of excellence to assist with taking this success on to other projects, and that seems to be working: the initial project cost them over $3M, and the next one – which is three times more complex – cost only one-third of that since BPM is now built into their enterprise infrastructure. And, at the end of the day, they’re seeing a 30% productivity increase in their initial implementations.

Their biggest challenges were the introduction of Agile and Spiral methodologies, the geographic dispersion of the team, and recruiting the right talent for their remote location; they used internal education both for the methodologies and to grow their own BPM specialists locally when they couldn’t recruit them.

There were several things that they did that he feels contributed to their success, such as daily headline meetings, engagement with the business, fostering team spirit, and highlighting and addressing the riskier requirements early so that they can be tried out by the business and tuned as required. He also felt that Agile was a huge contributor, since there were no more 300-page requirements documents that were either not read or not understood by the business, but signed off regardless. He finished with a few strategic lessons learned: begin with the end in mind, including planning how this will become part of the infrastructure; and pick a big project in order to ensure commitment and executive engagement.

2009 10 08 Sandy Kemsley BPM Comments (2)

Embrace Lean thinking to enable innovation #BTF09

The morning finished with a panel moderated by Dave West of Forrester, and including Kevin Haynes of Dell and Dave Smoley of Flextronics. West started out talking about the inertia within IT: more than 60% of IT is spent just keeping the lights on, legacy systems inhibit change and vendors are slow to change. There is, however, a wave of change coming, with Agile adoption at 36% and rising, 80% of developers using open source and new software development up by 9%.

Smoley told about their experiences at Flextronics, where Lean has spilled over from manufacturing to IT, allowing them to reduce their IT costs to less than 1% of revenue. They were able to reduce their IT costs by 36%, all while performing some major projects such as a new supply chain management system, a global HR system, a WAN refresh, a data center refresh and implementing a global service desk. He credits Lean with being able to determine what technology is important and what is unimportant to the business, allowing them to cut or rework the areas of waste. Their strategy includes a “just enough” mentality, putting the customer first, trying out hardware and software before they buy it, maximizing asset utilization, consolidating wherever possible, and enabling global collaboration. Projects are prioritized by ROI, and business alignment is done at multiple levels. They avoid single source, aren’t afraid to renegotiate maintenance contracts, and use open source and open standards where possible. They also bite the bullet and actually throw stuff out if it no longer is the best thing for them, which often requires putting people’s egos aside if they were involved in the original development or acquisition of a system that is being decommissioned.

Haynes related what they’ve done at Dell, which has been focused on keeping the lights on rather than innovation, but maintaining the important operations and customer service levels while spending less. Their strategy is focused on decreasing variability, focusing on projects that reduce costs while driving service excellence, and consolidation through virtualization and techniques such as reducing to three standard desktop images. All of this is not just about exciting new innovation, either: it’s just as necessary to focus on better ways to handle the steady-state maintenance projects as well, and automate them where possible to free up resources.

The discussion ranged across both strategic and operational aspects of how Lean is helping both organizations to reduce their IT costs, and way too much information for me to capture, especially since West seems to have ADD when it comes to handing the remote control to advance slides :)   There were some good takeaways about Lean, such as transparent reporting on value and waste, establishing the right team culture around a problem-solving approach, creating structure around value chains, and frequent delivery to allow for constant fine-tuning of the business value.

2009 10 08 Sandy Kemsley Comments (0)

The power of Lean IT #BTF09

John Swainson, CEO of CA, gave a presentation on how Lean can help companies built long-term competitive advantage during tough economic times in industries as diverse as manufacturing, healthcare, retail and IT, and how Lean IT – or what he referred to as the industrialization of IT – can deliver greater value at lower cost. As he pointed out, it’s about time that we applied some discipline to IT, and we can learn from how Lean helped other types of organizations to create just-in-time IT that deploys the right solutions at the right time.

Lean IT is about a “sense and respond” philosophy that has IT paying attention to what’s happening in the business and manage variable volumes, prioritize and create new business services, and ensure ongoing quality levels.

CA commissioned a study on waste, and found that 96% of IT executives agree that there is significant waste in their organization, primarily due to inefficient processes, duplication of effort, redundant applications, and underutilized assets; Swainson sees that the keys to resolving these issues is to analyze, automate, integrate and optimize (respectively).

He was then joined on stage by John Parkinson, CTO of TransUnion. As a credit rating/tracking service that tracks individual consumer credit ratings around the world, IT is absolutely central and critical to their operations, not just a support function. As the recession approached in 2007, however, they had to consider how to grow new sources of revenue and increase operating margins in order to decrease their dependency on the failing consumer credit market. Lean was part of their strategy, helping them to pinpoint the wasted effort and other waste, and allowing them to optimize their operations. With their corporate culture, they needed this to have this be more of a grassroots initiative that made sense to people: adopting Lean since it helped them to do their job better, not because of a corporate mandate. There is, however, monitoring and measurement in place, and performance and compensation are tied to improvements: the ultimate incentive. Their idea is to instill these Lean ideas into their culture, so that these good habits learned in tough times would serve them well when times improve.

Parkinson pointed out specifically that Lean sets you up for taking advantage of cloud computing, and Swainson took over to talk about the opportunities and challenge of working in the cloud. It’s pretty hard to embrace Lean without at least taking a look at using the cloud, where you can provision the right resources at the right time, rather than having a lot of excess capacity sitting around in your data center. Consider non-production environments such as test labs, for example: being able to create test environments as required – either through internal virtualization (which I don’t really consider to be cloud) or in an environment such as Amazon EC2 – rather than having them pre-installed and ready long before required, and sized for peak rather than actual load. Considering that test environments can be 2/3 or more of the server footprint, this is huge.

Mike Gilpin joined them for a discussion, which briefly continued on the topic of using virtualized or cloud test environments, but also covered the issues of how well contract IT employees can adapt to Lean cultures (if they don’t, then find someone else), using other techniques such as Six Sigma together with Lean (they’re all tools focused on process optimization, pick and choose what works for you), and the security challenges of using cloud infrastructure.

2009 10 08 Sandy Kemsley Comments (0)

George Colony on the CEO’s brain #BTF09

George Colony at Forrester Business Technology ForumWe had a brief address from George Colony, CEO of Forrester, on changing from IT to BT, with one key message: if your CEO doesn’t understand what you’re talking about, then you’re probably not using “BT speak”.

The CEO is focused on two things: higher profits, and revenue growth, and you need to translate your projects and technology strategy into those terms, or risk being marginalized within the organization.

A brief 10-minute address, but a good message.

2009 10 08 Sandy Kemsley Comments (2)

Lean and the CIO #BTF09

Tom Hughes, currently with CSC but formerly the CIO of the US Social Security Administration, spoke to us about Lean and the CIO. The imperative here is driven by surveys that show that (to paraphrase) business thinks that IT is important, but that they’re doing a crappy job. He believes that CIOs need to break out of the technology pack and focus on business outcomes (e.g., market share) rather than outputs (e.g., number of workstations): exactly the same message as Connie Moore gave us in the opening keynote. CIOs needs to be valid members of the executive team, reporting to the board rather than the COO, HR, general counsel or any of a number of other non-effective reporting structures.

He believes that the CIO of the future must:

  • Be a strategic thinker, not an IT techie
  • Be at the table of chief executives
  • Partner in agency or business transformation
  • Have broad experience

The CIOs focus needs to be on four things: strategy, budget, architecture and security. Delivery and maintenance, on the other hand, are operational issues, and should be handled below the CIO level, even directly in the business units by promoting cross-functional ownership. The CIO needs to be forward-thinking and set strategy for new technologies such as cloud computing and unified communications, but doesn’t need to be responsible for delivering all of it: for things that the business can handle on their own, such as business process analysis, let the business take the lead, even if it means acquiring and deploying some form of technology on their own.

He concluded with the statements that the CIO needs to work with the CEO and develop a collaborative operational model, be at the table with other senior executives, and get other executives to take accountability for how technology impacts their business area. The CIO needs to be seen by the CEO as a partner in business transformation, not the guy fixing his Blackberry.

Questions from the audience included how to transition the current technology-focused IT teams to have more of a business focus: Hughes’s response is that some of them will never change, and won’t make the cut; others can benefit by being seconded to the business for a while.

On a side note, I like the format of the keynotes: Mike Gilpin pops up on stage at the end of each one, he and the speaker move to a couple of comfy chairs at center stage, and he asks some questions to continue the conversation. Questions from the audience are collected on cards and vetted by Forrester analysts, who then distill them into a few key questions to ask.

There’s still a bit of confusion over the Twitter hashtag: the website says #BTF09, then Gilpin announced in the opening address that it is #FBTF09, but then @forrester DM’ed me that it is actually #BTF09 and that Gilpin will correct this, although that hasn’t happened yet.

2009 10 08 Sandy Kemsley Comments (7)

Why Lean is the new business technology imperative #BTF09

I’ve moved from the Gartner BPM summit in Orlando to Forrester’s Business Technology Forum in Chicago, where the focus is on Lean as the new business imperative: how to use Lean concepts and methods to address the overly complex things in our business environment.

Mike Gilpin opened the conference with a short address on how our businesses and systems got to be so bloated that lean has become such an imperative, then Connie Moore took over for the keynote. From the keynote’s description on the event agenda site:

Lean is not a new business concept — but it is enduring. By embracing Lean years ago, Toyota reached No. 1, while rivals GM and Chrysler collapsed into wards of the state. In its broadest sense, Lean seeks to better satisfy customer needs, improve process and information flows, support continuous improvement, and reduce waste. Today’s recession is a clarion call for businesses and government to reexamine and reapply Lean thinking across people, processes, and technology. When maintenance eats 80% to 90% of IT budgets, it’s beyond time to examine Lean approaches — like process frameworks, cloud computing, SaaS, Agile methodologies, open source, or other fresh ideas. And when the sheer complexity of technology overwhelms information workers, it’s time to simplify and understand what workers really need to get their jobs done. And by focusing on Lean now, your organization will be positioned to power out of the recession and move quickly into the next new era of IT: business technology — where business is technology and technology is business.

She started with discussions about how Lean started in manufacturing, and you can see the obvious parallels in information technology. In Lean manufacturing, the focus is on eliminating waste, and everyone owns quality and problems are fixed at the source. Lean software isn’t a completely new idea either, but Forrester is pushing that further to change “information technology” to “business technology”.

Lean is not just operational, however, it’s also strategic, with a focus on understanding value. However, it’s usually easier to get started on it at the operational level, where it’s focused on eliminating waste through improving quality, eliminating non-productive time, and other factors. Lean can be counterintuitive, especially if you’ve been indoctrinated with an assembly line mentality: it can be much more efficient, for example, for individuals or small teams to complete an entire complex task from start to finish, rather than have each person or team perform only a single step in that task.

Moving on to the concepts of Lean software, she started with the results of a recent Forrester survey that showed that 92% think that enterprise software has an excessive cost of ownership (although personally, I’m not sure why they bothered to take a survey on something so incredibly obvious :) ), and discussed some of the alternatives: SaaS such as Google Apps, open source or free software and other lighter weight tools that can be deployed at much less cost, both in licensing costs and internal resource usage. Like Goldilocks, we need to all start buying what’s just right: not too much or too little, in spite of all those licenses that the vendor wants to unload at a discount before quarter-end.

Looking at the third part of their trifecta, there’s a need to change IT to BT (business technology). That’s mostly about governance – who has responsibility for the technology that is deployed – and turning technology back into a tool that services the business rather than some separate entity off doing technology for its own sake. What this looks like in practice is that the CIO is most likely now focused on business process improvement, with success being measured in business terms (like customer retention) rather than IT terms (like completing that ERP upgrade on time, not that that ever happens). Stop leading with technology solutions, and focus on value, flexibility and eliminating waste. You can’t do this just by having a mandate for business-IT alignment: you need to actually fuse business and IT, and radically change behaviors and reporting structures. We’re stuck in a lot of old models, both in terms of business processes and organizational models, and these are unsustainable practices in the new world order.

There were some good questions from the audience on how this works in practice: whether IT can be Lean even if this isn’t practiced elsewhere in the organization (yes, but with less of an effect), what this means for IT staff (they need to become much more business focused, or even move to business areas), and how to apply Lean in a highly regulated environment (don’t consider required compliance as waste, but consider how to have less assembly-line business processes and look for waste within automated parts of processes).

2009 10 08 Sandy Kemsley business Comments (5)

Forrester Day 2: Colin Teubner

The last session of the last day, and a significant portion of the audience (especially those headed east) have bailed out but there’s still a few of us hanging around to hear Colin Teubner talk about optimizing business with BPM. I think that he drew the short straw as the junior guy, presenting in the last two sessions back-to-back. :)   I think that the two-day format is just the right length; the 2-1/2 days of Gartner last week was just a bit long. Also, starting on Tuesday so that people can travel on Monday rather than having to burn up half their weekend is nice, too.

The central theme is that the ultimate goal of BPM initiatives should be transformation, not just efficiency. As he points out, many companies focus purely on efficiency, trying to trim costs for small wins rather than looking to make a transformative change that can drastically improve the organization’s competitive differentiation and revenue. BPMS is more than just modeling and automation; it includes the whole cycle of monitoring and optimization feeding back to the modeling stage. He showed a slightly different version of the BPM maturity/adoption chart that Connie Moore showed yesterday; I’m still unsure why this is a two-dimensional graph, since it is really a projection on the diagonal axis, but I suppose a one-dimensional representation just doesn’t look as nice.

He then mapped BPM onto the “design for people, build for change” theme of the conference: UI creation and process mindset belong to the design for people side of things, whereas agile processes, SOA connections, business-friendly tools and comprehensive monitoring map to building for change. Different from, but compatible with, the view of BPM in the D4PB4C theme that I covered on slide 26 of my presentation this morning. He talked about why simulation tools are not used as widely as the BPM vendors would have you believe: they’re too hypothetical and require a certain amount of guesswork (although using detailed execution data to populate your simulation can help with this). I also think that they’re a bit too complex and analytical for many of the business analysts who are targeted to use them.

Tuebner covered a number of use cases for BPM integrated with other technologies — forms technology to integrate data from other sources, content, BI and more — and the ways in which BPM enables an improved customer experience both through direct interaction or by informing the environment of an internal employee who is dealing with the customer.

He showed (for about 10 seconds) their Q3 Wave for BPM vendors; I think that this is the human-centric BPM wave, although it really went by so fast that I didn’t catch it, much less any of the vendors’ positions on it.

He had some interesting words about end-to-end organizational visibility and how it allows executives to understand processes and systems by making the link from strategy goals down through other layers; not surprisingly, he discussed this in the context of enterprise architecture.

His final recommendations:

  • Don’t just make processes run faster, make them better and pay special attention to users’ work environments.
  • Use BPM for business improvement, not process improvement, and focus on customer experience.
  • Take an end-to-end view of process and plan BPM as a management discipline (by which he means a business initiative).

That’s it for the Forrester Technology Leadership Forum. I’ve enjoyed it, found the content solid, and the culture a refreshing change from some other large analyst conferences.

2007 09 26 Sandy Kemsley BPM Comments (0)

Forrester Day 2: The three B’s

I ended up skipping the session after mine at the end of the morning, but had some great hallway conversations with some of the business rules vendors who indicated that they think that I’m on track with what I’m saying about BPM and BR.

For the first of the afternoon sessions, I’m attending a panel discussion on the convergence of the three B’s — BI, BPM and BR — featuring Mike Gilpin (EA and application development), Boris Evelson (BI) and Colin Teubner (BPM). I covered a tiny bit of this topic in slides 22-24 of my presentation this morning, and will be doing a full-length presentation on this same topic at the Business Rules Forum next month in Orlando, so I’m interested to see if the Forrester analysts have the same thoughts on this subject as I do.

They start with the statement that “design for people, build for change” will drive the convergence of the three B’s. Interestingly, although a few people in the room stated that they use BPM and BI together, almost no one raised their hand to the combination of BPM and BR — a combination that I feel is critical to process agility. Gilpin went through a few introductory slides, pointing out that almost no business rules are explicitly defined, but are instead buried within processes and enterprise applications. He sees BI as driving effectiveness in businesses, and the combination of BPM and BR as driving efficiency.

Forrester will be publishing some reports about the convergence of the three B’s, and although there are some two-way combinations in vendor products now, there are no vendors that combine all three in a single product. I’m not sure that this is a bad thing: I don’t think that we necessarily want to see BR or BI become a part of BPM because it ultimately limits the usefulness of BR and BI. Instead, I see BR and BI as services to be consumed by BPM, with BI having the additional role of combining process execution statistics generated by the BPMS with other business data. An explicit question was asked about when to use the BR and BI included in the BPMS versus when to use a third-party best-of-breed BR or BI system; Teubner and Gilpin offered some guidelines for this as well as some examples of each situation, but it’s not completely clear if there’s a distinct boundary between when to use the BPMS’ in-built functionality versus the third-party specialist product.

My message on this topic is that BR is the key to process agility, and BI is the key to process visibility as well as feeding back into BR in order to further increase agility. By using the BR and BI functionality within your BPMS, however, you’re typically not getting full BR or BI functionality, but some limited subset that the BPMS vendor has selected to implement. Furthermore, you can’t reuse that functionality outside the BPMS, and in the case of business rules, a change to the BPMS’ rules often requires retesting and redeploying the process models, and does not apply to in-flight processes. However, if you’re not sure if you need BI or BR (hint: you do), then using the in-built functionality in the BPMS gives you an easy-to-integrate and lower cost way to get started. Moving to a separate third-party business rules system gives you a couple of key advantages: you can reuse the same rules across different processes and across other applications in your enterprise, and changes to the rule impacts in-flight processes since the rule is not executed from the BRE until that point in the process is reached. Moving to a separate third-party business intelligence system also provides the advantage of being able to analyze the process data in the context of other business data, and potentially feed back the results of complex analytics to inform the business rules, that in turn drive the business processes. The bottom line: BR and BI are used for many applications in the enterprise that are not explicitly process-related, or combine data from many systems of which the BPMS is just one source. For example, although there are processes embedded within your ERP system, your BPMS may not have direct access to all the information that’s in those processes and hence the BI that’s part of your BPMS can’t (easily) include that data in its analytics and reporting; a general-purpose BI platform may be much more suited to combining your BPMS statistics with your ERP statistics.

A lot of the conversation in this session, which was very interactive with the audience members, was around whether to use converged products versus separate products. It’s not a completely simple answer, and I’ll definitely be thinking about the use case boundaries between converged and separate products before I show up at the Business Rules Forum to continue this discussion.

Evelson and Teubner will be publishing an initial paper in this area in the next few weeks, using the concepts that they’ve presented here today, but see it as a springboard for more discussion in this area rather than an end-point.

2007 09 26 Sandy Kemsley BI
BPM
BRM Comments (8)

Forrester Day 2: Skipping class

I skipped the opening keynote by Shantanu Nayaren of Adobe and the talk by cognitive scientist Don Norman; my presentation is at 11am, and although I’m not a particularly nervous presenter, I felt that my time was better spent reviewing my notes, especially considering that I’ve crammed material from the three one-hour webinars that I did for TIBCO and my upcoming presentation at the Business Rules Forum into a single 30-minute blast. You can see my slides here (use the controls at the bottom to move through the slides right on this page):

My only regret is missing Forrester’s opening short video of movie clips illustrating the “design for people, build for change” message; the ones yesterday were very funny, and I hope that they post them all on YouTube.

2007 09 26 Sandy Kemsley Comments (5)

Forrester Day 1: Packaged Applications panel

We finished up the day with a panel of Forrester analysts addressing the issue of whether packaged applications (i.e., ERP software) will ever be designed for people and built for change — that is, can these apps ever be agile. This was structured as a debate monitored by Merv Adrian, pitting Sharyn Leaver on the business side against John Rymer on the IT development side.

Adrian started by repeating the four principles of dynamic business applications that Connie Moore discussed this morning, then framed some questions for the packaged application version:

  • Will packaged applications contextualize work using unitary but dynamic workplaces?
  • Will packaged applications enable up-front customization to meet unique customer needs? (The feeling is that apps will be customizable “at the edges” only in order to allow for future upgrades/agility)
  • Will packaged applications enable ongoing adaptation for continuous business evolution? (Yeah, right)
  • Will packaged applications allow development and change by business people and IT professionals in cooperation?

Leaver and Rymer duked it out over each question, providing some really interesting viewpoints. It wasn’t exactly impromptu; each question had at least one backup presentation slide from one of them to make their point. They ended up with a slide comparing the four application biggies: Oracle, SAP, Microsoft and IBM.

From my standpoint, this was the least interesting presentation of the day, since I don’t focus on packaged applications, although it was an interesting “he said, she said” debate format. The general agreement is that the gap is narrowing between build and buy+customize, but that most customers will still require customization for competitive differentiation.

Tom Pohlmann popped back up at the end of the day with some closing remarks, then directed us off to the vendor showcase reception and the pool party. Given that it’s only 21C here in Carlsbad — compared to a balmy 28C back in Toronto (even though it’s already after dark there) — I don’t think that anyone’s going swimming tonight. Since I’m still on Eastern time, I’ll probably be asleep by 9pm again tonight.

2007 09 25 Sandy Kemsley Software design Comments (0)

Forrester Day 1: Automating Business Processes panel

Connie Moore moderated a panel on automating business processes, featuring David Knapp of Ford, Pamela Rucker of Philip Services and Theo van den Hurk of ABN AMRO. The room is considerably less crowded than this morning, so I’m guessing that there’s some golfing going on (probably all the CIOs whose golf games were rained out last week at the Gartner conference in Orlando). I really like how they use the big projection screens to show live video of the panelists; I’m sitting way over on the side to score some power for the laptop, so can’t see two of the presenters directly.

Moore talked about Forrester’s BPM maturity framework, which I’ve never seen before but it’s similar enough to BPMM and others that I’ve seen: moving from process knowledge to process efficiency to process consistency to business optimization to business transformation, where most companies are in the efficiency stage, moving towards consistency.

Each of them told a bit about what they’re doing with BPM:

  • Ford is another Lombardi customer that’s just getting their implementation started (it’s sort of ironic, considering that Ford pioneered the concept of the assembly line, that they’re only now getting around to business process automation). They’re a big Six Sigma shop, and are looking at getting some automation and metrics in place, then drive towards optimization using BPM. They’re using BPM in large part for orchestration of their existing legacy systems.
  • Philip Services has a mandate to innovate, but no extra budget to do so, which is a common problem in organizations; they don’t use BPM software but are effectively building their own in code or within the enterprise systems.
  • ABM AMRO is using SAP and Oracle as their enterprise systems, and as far as I could tell, they’re not using a BPM suite to orchestrate that but are relying on the processes within those enterprise applications.

Knapp showed an interesting slide if how BPM bridges the gap between end user computing and full-on IT application development; I think that there’s also an overlap between mashups and BPM at some part of that spectrum. Ford has an enterprise process committee that looks at process management across the organization, especially focussing on the discontinuities (hand-offs between functional silos), and decides which processes to implement. However, they’re still narrowing down and deciding which processes to implement.

Rucker said that two major issues for them was having the business take ownership for business process management, and getting away from siloed process optimization (like the accounting department) to look at end-to-end processes (like order to cash). They even got the CEO involved to drive home these points home to people.

van den Hurk talked about the complexities introduced by having several outsourced vendors involved in their systems as well as their own IT people; just getting all the stakeholders to sit down together was a challenge. ABN AMRO looked at heat maps for operational budget areas to figure out where the money was being spent, as well as what the business reported as the pain points.

There was a question about metrics, monitoring and dashboards: Ford is designing it into their systems; Philip put it in after the fact when they realized that processes weren’t improving and had no visibility into why; ABN AMRO also is building it in based on the business needs.

As panels go, this was pretty conversational rather than a series of mini-presentations: good to attend, but harder to blog about in a coherent fashion.

2007 09 25 Sandy Kemsley BPM
Lean Six Sigma Comments (0)

Forrester Day 1: John Rymer

John Rymer, who I’ve read before on business rules topics, talked to us about why we should care about business rules software; Forrester’s position is that business rules are a key enabler of design for people, build for change.

He started with definitions of business rules and a business rules platform, then went on to state that business rules are an alternative to conventional programming: with business rules you don’t have to translate business terms into geek speak, and you don’t have to specify every possible combination of rules works. The implications are that business people are most likely to get what they need since they can actually understand the “language” in which the rules are written, and more complex problems can be more easily solved with much less time required to change systems. Software can even adapt based on the results of the rules; BPM is just one example of this, but business rules can be applied in the same way in other types of software.

Rymer showed how business rules can be applied in the areas of the “perfect storm” that Connie Moore mentioned this morning as causing the transformation that’s underway now: design evolution (rules add adaptation to context and design), process evolution (rules enable decisioning, auto processes, closed loops), workforce evolution (business people contribute to rules) and software evolution (rules enable global policies for SOA, service selection). He went on with a great list of how organizations benefit from business rules:

  • Create applications that adapt; automate decision in response to business conditions
  • Create applications that change quickly; one set of business rules for all applications rather than having the rules spread through a number of different applications and code sets
  • Tackle the next automation frontier, decisions; capture the wisdom of the experts in rules where possible
  • Put analysis to work through automation: take action using business rules and BPM

He gave some good examples from financial services, showing how business rules have been applied to core tasks such as credit scoring and underwriting, then expanded to areas such as fraud detection and call center programs.

He highlighted that business rules allow organizations to divide change management responsibilities, where business people take responsibility for maintaining the more volatile rules and processes, whereas IT remains responsible for maintaining the core rules and processes.

He ended up addressing the issues of why business rules haven’t really caught on; I see so little acceptance of this with many of my financial services customers and I’m not surprised, although it seems strange that a technology that can offer so much benefit is being ignored by so many companies. The top reason for not implementing business rules? “We don’t do things that way”, that is, they like to write their rules in Java code instead. He also cited lack of standards, high product cost (which I still don’t think is more than writing and maintaining that Java code), lack of participation from the big vendors, and a still-shifting landscape as other reasons for resistance to business rules.

Like Rymer, I believe that business rules will be a significant part of any agile organization. In some cases, organizations already have business rules software but it’s hidden away in one department, but you need to pull it out of the closet and put it to work. Forrester has a Wave (product comparison) for business rules, but he admitted that it’s a bit out of date; it sounds like a new one might be coming out shortly.

2007 09 25 Sandy Kemsley BRM Comments (0)