System iNetwork

May 2007

May 29, 2007 3:40 PM

BPM: A Software Type in Search of a System i Market

Let's say you decided that what your company needed was a good BPM application that runs on the System i. If you didn't know any vendors who offered that type of software, you'd probably start by calling up your favorite search engine and be off to the races looking for web sites. Except in this case, that wouldn't work.That's because there are very few System i BPM vendors in one sense, and maybe only one in another. And yes, this is a trick question.

BPM is one of those devilish problems in IT jargon, an acronym with two meanings, both of which apply to software. But the meanings are actually about as alike as Danny DeVito and Arnold Schwarzenegger were in the movie Twins. Like the two actors who have some broad common features (e.g., they're human, they're male), the two BPMs are concerned with analyzing business processes based on computer algorithms, but it's actually the overarching similarities that make things confusing.

The more common meaning of BPM is "business process management." Generally speaking, those are the acts of planning, managing, and analyzing operational business processes. In other words, coordinating business activities. You could almost say this kind of BPM is what corporate vice presidents are supposed to do. But before you try to talk your CEO into replacing your least-favorite veep with some software, realize this BPM is more technical than most corporate officers are. For example, this type of BPM has its own language, called Business Process Execution Language (BPEL), which is a modelling tool based on eXtensible Markup Language that lets users define business processes . . . but from one person's point of view rather than, for example, the organization's as a whole. So in a broad sense, BPM here means control of business activities such as workflow, coordination of timing of subprocesses, and even coordination of multiple existing software applications in a way that merges into the realm of web services and service-oriented architecture (SOA).

The other BPM is "business performance management." This is the organization and control of information and metrics for evaluating how a business overall is performing, activities that focus on key performance indicators (KPIs) (metrics that can be assigned specific values) and gathering and analysis of data from documents, databases, data warehouses, and other sources. In other words, business intelligence (BI). Except of course the practitioners of this type of BPM see it not as BI but "the next generation of BI," which means to them that all the purveyors of query tools, data miners, decision support systems, executive information systems, dashboards, and similar BI-type applications don't really offer BPM, just elements of it.

So what's this mean to a System i user? It means that there are few software offerings for the first type of BPM available that run under i5/OS. And as for the second type, while there are query tools, report writers, dashboards, and business intelligence tools of many sorts that run on the System i, there is only one that claims to provide unified "business performance management," Lawson's ( http://www.lawson.com ) Enterprise Performance Management for M3.

In the business process management area there are several System i vendors. For example, RJS Software's ( http://www.rjssoftware.com ) Enterprise Workflow helps users "design and manage electronic workflows for documents that used to be processed manually" and "map the routes documents take within a particular work process." That company's WebForms gives users "the ability to create dynamic XML forms to capture and share business information." Seagull Software ( http://www.seagullsoftware.com ) offers LegaSuite BPM, a Java-based suite that transforms applications into web services to facilitate business process management and SOA. GeneXus ( http://www.genexus.com ) provides GeneXus BPM Suite, which helps users automate and manage business processes.MNI Solutions ( http://www.mnis.co.uk ) has authored iSeries TaskCentre, a BPM suite that blurs the lines between BPM types by promising not only workflow tools for tasks such as credit limit changes, document sign-offs, and production schedule changes, but also offers KPI alarms, workload exceptions, and financial warnings. Oracle/PeopleSoft/J.D. Edwards' ( http://www.oracle.com ) World Express is an ERP package that includes workflow and a number of other capabilities that give it a claim to business process management chops, if not an aspiration to be the BI type of BPM.

If there are additional vendors with products that qualify in this area, please make a post and add yourselves to this list!

My final question is why there should be so few BPM vendors of either type for the System i. Don't businesses using the platform need to coordinate and model internal processes? Couldn't every business use something more than BI to help keep an eye on its financial health? I'm sure it's true that because so many System i enterprises are small businesses, they can't afford to buy what every CEO thinks they're born to do anyway. But there are many medium-to-large System i enterprises that could benefit from either kind of BPM software. Could these be areas of future growth for our market?

Posted by on May 29, 2007 at 3:40 PM | Comments (5)

May 21, 2007 2:24 PM

Are You Too Busy to Take a Summer Vacation?

With Memorial Day weekend upon us, it's official! Summer has snuck up on us again. So although I had a software topic picked out to get into today, let's put that off and this week talk about something really fun: Time off!

Or, how impossible it can be to actually take time off. What got me thinking about this (besides looking in dismay at my wall calendar) was that Yahoo HotJobs ( http://hotjobs.yahoo.com ) issued a press release this morning about a survey it just completed on U.S. workers and their vacations.

I'm in no position to evaluate Yahoo's methodology, so I'm just going to assume for the sake of argument that the survey findings are at least approximately correct. While the survey purports to apply to U.S. workers as a whole, I think it's fair to presume that IT workers in the System i market, if not actually worse off, are somewhere in the same ballpark . . . but what a sad venue that is if Yahoo's statistics are true.

Apparently, although 74 percent of U.S. workers get at least two weeks of paid vacation, 45 percent of those same workers didn't use all their vacation time in 2006. Why? Because 36 percent feel they have too much work to do, 34 percent feel they can't afford to go away, 32 percent prefer to preserve and roll over their vacation for emergencies, and 15 percent are anxious about the workload they'll face when they return from any significant time off. Doesn't that sound strangely familiar?

Not only that, but among those who did take their time off, 28 percent limited themselves to only one or two consecutive days at a time. Perhaps that's at least partly because of some other statistics Yahoo reported. Of those surveyed, 30 percent use vacation time as "mental health days," 31 percent use them to run errands or catch up on housework and other personal business, and 32 percent use them to interview for new jobs -- all of which seem to encourage a onesy-twosey philosophy towards vacation-day use.

Let's skip the usual digression you might be expecting here about how workaholic we all are and the habitual envious statements about Europeans ("Hey, Charlie, is it six days a week, six weeks a quarter, or six months a year paid vay-cay those guys get?"). I will note that I went to a one-day seminar for editors last week, and the seminar leader's observation (which was contested by none of the 60 or so people attending) was that "strict" editing styles are vanishing because workloads are so high that few can afford to spend enough time on any one piece of copy to apply truly strict editing practices anymore. Many IT and other kinds of workers are facing the same kind of reality.

And this doesn't just apply to vacations. Last November, CCH, Inc. ( http://www.hr.cch.com ), a company that provides business and corporate law information services, issued results of a survey it did on employee use of sick time. That study noted 66 percent of respondents said they didn't take sick days even when they were sick because they had too much work or were afraid of missing a deadline, and 56 percent said no one was available to cover for them. The bottom line for both vacations and sick time is that for many people there's too much to do and no one who can take up the slack if a worker is out of the office for any reason. Under these conditions, not taking vacation can seem not so much a self-deprivation as it is a smart move in the game of catastrophe management.

Yet we all know that it's unwise to do this. The whole point of time away from work is that we need the mental recharge we get from spending time with people and pastimes we enjoy, and even just the release of thinking about something other than the to-do list on our desks for a while. Often when we return, we think better and work more efficiently. If it wasn't for that benefit, probably few companies would even offer vacations. Modern life is stressful enough, even if you never watch the news, that we need our days off.

Of course, if you're one of the 26 percent that Yahoo says doesn't even get a vacation, you have the sympathy of all the rest of us. But even those who get paid vacations can face considerable restraint on their freedom to actually take advantage of it.

Will this summer find you in the "no-vacation" metaphorical boat rather than in an actual one with a fishing pole in your hand -- or whatever it is you'd rather be doing than staring at stuff 20 inches from your nose most of the day? What's your biggest fear about taking (gasp!) five consecutive days off? Is it do-able for you, even if only once in a while . . . or is it always asking for more trouble than it's worth?

Posted by on May 21, 2007 at 2:24 PM | Comments (2)

May 14, 2007 2:53 PM

Gettin' SaaSy With It

If you take a peek at IT publications outside of the System i market, one term that seems to be all the rage these days is "Software as a Service," or SaaS. Basically, this is the practice of offering software applications via the Internet instead of licensing them to run on a client enterprise's own machines.

In our market, the concept isn't really new. Back in the 80s and into the 90s there were "Service Bureaus," which offered green-screen apps running on someone else's AS/400 and largely accessed by private connections. Later came Application Service Providers (ASPs), which added the twists of offering client/server apps over public networks, eventually with HTML interfaces. Then came Managed Service Providers (MSPs), which tossed some networking equipment and services into the mix, as well as the ideas of also being a host to multiple web sites or providing an enterprise with general Internet access.

Yes, I realize I'm oversimplifying. The point I'm trying to get to is that conceptually SaaS is largely a recycled idea in the System i market, and one that has always found no more than limited acceptance. The number of successful Service Bureaus, ASPs, and MSPs in the System i world has never been large. Partly, this was due to the expense of connectivity solutions before Internet use became widespread and the inherent insecurity and relative unreliability of network communications in decades past. Even more, I think, was the prevalence of what used to be called the "not invented here" syndrome, the egocentric idea that one's enterprise was too unique to use software that wasn't custom-built to handle those home-grown eccentricities that were each company's "secret sauce."

Nevertheless, SaaS is a term that's spreading throughout the Windows part of the computing world and becoming trendy because Microsoft uses it. But I wonder if, after all the years of knocking around in its SB, ASP, and MSP forms, SaaS isn't an idea whose time has finally come even in the System i market.

SaaS makes some economic sense, for SMBs particularly. After all, it's a way that promises to offer browser-based access to proven applications for System i end users while bypassing many of the IT resource-consuming activities that are often hard for SMBs to fund: guaranteeing service levels to the users, managing backup windows and media for applications and data, introducing software upgrades without causing at least minor trauma, and in some cases, even making custom modifications to apps. And with SSL/TLS and other forms of encrypting confidential business data moving across the Internet in place and performing reliably, and the ubiquitousness of ISPs offering reasonably priced access to the web, the instability, insecurity, and expense that hampered the ASP business model in the past is disappearing. It's still not perfect, of course, but so much better than it was. And with the system management tools becoming available, it's more economical for a company that offers application software to start thinking, "hey, we could handle keeping separate from each other the transactions of multiple client businesses running our software on our machines."

I think there's a new psychology at work among users as well. Even many SMBs are feeling the heat of needing 24/7 uptime to support computer-based consumers who don't follow the mindset of only doing business doing "business hours," or to support potential markets in more than just the U.S. time zones. The idea that only custom software can support "business done our way" is starting to give way to the thought that, particularly at small companies: "well, if the software companies successfully selling these apps seem to expect us to run our inventory system a particular way [for example], maybe we should be changing our inventory system to conform to the software. How hard can that be?" Granted, larger companies can't do this without considerable pain. But small, nimble companies can take advantage of such expediencies when they don't have the resources to develop custom alternatives on their own. And in an era of increasing business consolidation that often requires merged companies to conform their business practices to an application software standard that may be unfamiliar, even large companies are finding it necessary to change their internal methods, sometimes drastically, to fit software rather than the other way around.

In the past few months there have been some signs of a move in a SaaS direction by some companies that include System i support in their repertoire. In February, Voltage Security offered Voltage Security Network, a managed encryption service for e-mail messaging that includes Domino servers like the System i. In March, Esker unveiled Esker Fax Services for SAP applications, a SaaS offering that lets users send faxes directly from their SAP applications, and Lawson Software announced Lawson Total Care Platinum, a managed hosting solution for its ERP applications that lays the groundwork for those apps to be offered on a SaaS basis across all platforms Lawson supports, including System i. Particularly in the case of Lawson, this is a move by an application software heavyweight that could offer it some traction with smaller companies. Little guys that may not be able to afford to purchase Lawson software licenses for use on their own machines might be able to afford SaaS services for the same products if backups, service-level guarantees, and help desk support were part of the deal.

Do you think SaaS is an idea that makes sense for the System i market? If you're an application software vendor, are you thinking about offering your products on a SaaS basis to smaller companies than those that are currently the bulk of your user base? If you're at an SMB user company, would apps on a SaaS plan be affordable even when an outright software purchase might not be?

Posted by on May 14, 2007 at 2:53 PM | Comments (5)

May 1, 2007 4:59 PM

A New Channel for Solutions Information

Welcome to Product Lines, a new blog about third-party product solutions in the System i market. You probably know me best from my monthly Product Guy column or various product-related articles in System iNEWS and here at SystemiNetwork.com. While this blog will have something in common with that, it's also going to be a major departure.

I've been covering the products beat in the AS/400-iSeries-System i market for nearly 17 years now, so I have a little experience, you might say. I hope to provide you with a few insights from time to time about the software products that provide solutions for so many people, as someone who's used to looking at product offerings from a vendor-neutral point of view. But far from this new blog being all about me, I really want it to be much more about you, the users (and even the vendors) in our market.

After all these years, it's my observation that despite so many of us being "information professionals," it's kind of surprising how little information we get to use sometimes in making decisions. I've heard so many stories about people at small-to-medium businesses (SMBs) who, pressed for time and resources needed to do a thorough product search, buy a solution for which they took a demo because someone they network with heard of someone else's company that had a good experience with that product. But then they end up with buyer's remorse later because whatever that product was, it really didn't work the way they expected or it failed to meet their actual business needs in some crucial way. I think it's unfair to write this off to lack of due diligence -- there's an awful lot of product information to sift through out there in the world and even the best search engines and portals can sometimes miss crucial information just because of how people state their search terms.

I'm writing this initial entry from COMMON Anaheim and I saw an example of how this sort of information disconnect can happen -- just since lunch. I was standing at the booth of a vendor that, in part, offers a portal product with security features. A woman walked up and started to make a routine inquiry about providing her users with a way to access business information. It turns out that she's the single developer at her shop, is snowed under with projects, but her boss has insisted this needs to be a new priority. So she's at COMMON, looking for product information between sessions. The vendor explained his product, and every time she inquired about a feature, the vendor said, "we have that." They exchanged contact information and she walked away. "See that?" the vendor commented to me. "She didn't even know our product existed until she walked up to this booth."

Is this "mutual ignorance until ten minutes ago" the fault of the woman from the one-person shop? Hardly. She's buried in work and probably wouldn't have even made an inquiry except that her management suddenly shifted her priorities, so she's doing what research she's had time to do so far. Is it the fault of the vendor? No again, it's a company that has advertised in midrange publications for many years and has always seemed to me to be very diligent about getting the word out about its offerings. So it's no one's fault, and had this woman simply bypassed the vendor's booth because she thought of the vendor, "oh, he's busy talking to that guy," an important connection could have been delayed for weeks . . . or maybe forever.

And after talking to vendors for so many years, I see how their problem is that when it comes time to decide what features to include in their next product, or the next release, their feedback is largely limited to comments and requests from customers and prospects and from eyeballing what their competitors are up to lately. Good information sources to be sure, but certainly not the complete story when trying to assess market needs. The real problem that everyone shares is that we've collectively reached the point where there's too much information out there to efficiently sort through it all. We're all limited to doing the best we can with the time and information resources available to us.

So here comes "Product Lines." Yes, more information, but hopefully focused enough to be of use to both buyers and sellers. My goal is for this space to become a forum for discussion of such topics as what makes a product good, what people need from product solutions that they're not finding, and what features a consensus of potential product buyers think should be in the "ideal" application development tool, business intelligence solution, application software package, or what have you. In this weekly blog, I'll try to keep the ball rolling on discussions with a hopefully not-too-long entry about such topics as offerings outside our market that maybe provide a good model for products in our market, new products within our market that are offering the best of new features and functions, and other info of use that happens to scroll across my monitor. I'll try to keep it light, and I invite participation from anyone who wants to contribute, from wish lists to pointers to products that may already exist that meet a need. If the outcome is users getting what they need to do their job and connecting them with vendors selling solutions that satisfy those needs -- and incidentally helping keep our System i market vibrant -- I'll have done my job.

I've spent enough time explaining myself, so I'll close with a general question to the end users among you (that should be everyone, right?), some answers to which will hopefully launch us all on a voyage of discovery of sorts. The question:

"What do you need to do your job, or meet the needs of your business, that you don't have?" Please tell me. Your answer doesn't have to be long, although it can be. But let's just start with that and see where it goes. Hopefully, even if I don't hear from all of you, we can bring at least a little more illumination to the search for useful tools with which to "get the job done."

Posted by on May 1, 2007 at 4:59 PM | Comments (1) | TrackBack