Thursday, July 25, 2024

The Enterprise Spectator Has Moved to Substack

I have now moved this blog to Substack. Please visit the new Enterprise Spectator home page now and subscribe so you do not miss new posts in the future. (If you prefer to browse the site without subscribing, just click “No thanks.”)

I have already migrated posts from the past several years, and all new posts will only appear on Substack. I am also migrating the top posts from earlier years. This site will remain only as an archive because of the many inbound links developed over 20+ years. 

History of the Enterprise Spectator

In 2002, I launched the Enterprise System Spectator, one of the first technology blogs, first on Blogger, and in 2024 I migrated it to Substack. My initial focus was on enterprise technology, especially around enterprise software, such as ERP, CRM, HCM, and supply chain. In recent years, I expanded this focus to include business strategy and best practices in business management. As a result, I recently dropped the word “system” from the title. 

Reflecting my 50+ years working for and consulting to end-user organizations, I always take the perspective of technology buyers, not sellers. Although I have been interacting with tech vendors as a consultant and a research analyst, I sit unequivocally on the buyer’s side of the table. I tend to take a critical view vendor hype and inflated promises. I definitely have a contrarian streak.

My Career Journey

I graduated from the University of Pennsylvania in 1973 and shortly thereafter started my first job in IT for Macy’s at its headquarters in New York. I spent the next decade in corporate IT and the next 10 years as an independent consultant, followed by eight years helping to grow a small system integration firm to over 110 employees. 

Following the bust in the technology sector in 2000, my partner and I founded our management consulting firm, Strativa, and in 2005 we acquired Computer Economics, an IT research firm, founded in 1979. I sold both firms to Avasant in 2020 and retired in 2024.

Although I am retired from employment, I am not retired from the industry. I am continuing my role as an industry analyst here on the Enterprise Spectator. In addition to covering current trends, I am also documenting the many lessons learned over my long career. Although the technologies have changed greatly over those 50+ years, the lessons learned still apply. The technologies may be new, but the lessons are timeless. Scroll back through the publication archives and you can read them all, free.

Please visit the Enterprise Spectator on Substack and do hit the subscribe button (free). 


Thursday, July 04, 2024

Building a Consulting Firm and the Value of Independence

Frank Scavo, circa 1995
In this series on lessons learned in my career, we most recently covered my first decade as an independent consultant, ending with my first ERP selection project at Toshiba America Medical Systems. 

But as I was wrapping up my work at Toshiba, the US economy was entering the 1991 recession. Referrals from former Smith Tool coworkers had finally dried up. Nevertheless, there now was one new opportunity, but it would eventually mean giving up my status as an independent consultant. 

It was an opportunity offered by VC and DM [1], previously from the local SSA affiliate in Southern California, where they had represented BPCS at Toshiba. They had recently launched their own system integration firm, (hereafter, the “SI Firm”) to provide ERP implementation services to multiple software vendors. From my two years at Toshiba, I had the BPCS experience they needed. Would I be interested in joining them? Being out of work and with a young family to support, I accepted their offer. 

I was the third or fourth consultant hired, first as a contractor, then a couple years later as a full-time employee, and eventually senior vice-president and a member of the leadership team as the firm grew to over 110 employees. This post outlines what I learned over eight years in supporting the owners in building a consulting firm of some scale. 

My Time in Prison

That initial opportunity was with the Prison Industry Authority, which is part of the California Department of Corrections. CALPIA, by which it is now known, was in the middle of a BPCS implementation to support its manufacturing operations in, at the time, 26 state prisons [2]. The project was being led by Deloitte & Touche, but they were short of BPCS specialists. So, the opportunity was to subcontract me to Deloitte. 

But the project was in trouble. As described to me, the first team of Deloitte consultants had what might be described as some unrealistic expectations. They wanted to make CALPIA a Class A MRP implementation. Coined by Oliver Wight, Class A was the highest standard for MRP, based on a check list of assessment questions. Although Oliver Wight has since expanded the assessment to cover all areas of the business, the first checklist, published in 1988, was limited to defining excellence in the use of MRP II systems. I knew all this from my years of teaching APICS courses. 

Lesson #1: Set a Realistic Definition of Success

But, as noted, these expectations were not achievable. CALPIA was staffed with a combination of free staff and inmates [3]—not a particularly fertile ground for establishing world class manufacturing practices [4] [5]. As a result, the project went nowhere, and the initial team of consultants managed to offend nearly everyone at CALPIA with their quest to get to Class A MRP II. The new project manager, a more experienced senior manager from Deloitte, with the approval of the steering committee, developed a new project charter with more realistic objectives. The goal was now to just implement bills of materials and routings, inventory control, purchase orders, shop orders, and sales orders. The key metric was to achieve inventory accuracy of at least 90%—a low bar by Oliver Wight standards. 

So, I went around California working with free staff and inmates to successfully implement this functionality in seven of those state prisons. From this experience I learned that you need to recognize when ambitious objectives are simply not possible. You don’t get credit for setting lofty goals and not achieving them. In some cases, it is better to set a lower bar that the organization can realistically achieve. You can always come back later and raise the bar a little for the next stage [6]. 

Lesson #2: The Pros and Cons of Tech Vendor Partnerships

I could focus this post on the many other lessons I learned about ERP selection and implementation over my eight years at the SI Firm. But I think it is more interesting to talk about what I learned in helping to build and run a professional services business, specifically one largely focused on enterprise IT. 

As noted, from the beginning, the owners planned to provide implementation services for multiple ERP systems. They started with BPCS, without a formal partnership with SSA, the vendor. After a short time, they assigned me, with DM, the responsibility for the BPCS practice. For some years thereafter we built a successful consulting practice in following the local SSA affiliate around and turning around their failed implementations. At the same time, VC was developing our partnership with JD Edwards, which she later turned over to Nick Testa, a long-time friend of mine, whom I introduced to the firm. After two or so years, they added a partnership with QAD, which grew quite quickly, and I assumed leadership of that team a year or two later, along with my ongoing management of the BPCS group. Finally, around 1997, the firm established a partnership with Oracle. So now we had four ERP implementation practices. 

Partnering with tech vendors is a common strategy for system integration firms. Vendors can be a steady source of leads, and the partnership gives credibility to the service provider. The vendor also provides technical training and support. But there is a risk of becoming too dependent on tech vendors. Vendors are notorious for channel conflict, keeping the best leads for themselves, changing the terms of their partnership programs, or eliminating them altogether. So, there is an imbalance of power between vendor and partner. The owners of the SI Firm attempted to counter this risk by not basing the business on a single vendor. As discussed, we had four. So, this should have diversified the risk. When one partnership was weak, the others might be stronger. Until they all collapsed. 

Which is exactly what happened in late 1999. Our vendor partnerships all fell apart, each for a different reason. The end of the Y2K boom in ERP sales was certainly one cause, but there were other issues as well. We had hired substantial numbers of new consultants over the previous two years and had grown to over 110 employees. The owners had purchased an office building in Newport Beach, increasing the financial commitment. But now, clients were postponing or cancelling new projects and stretching out payables. Vendor partners were terminating our relationships. In 2000, we went through a massive layoff, of which I was a part. The firm would not survive much longer. 

If we did not have vendor partnerships, would we have suffered the same fate? Perhaps, but we would not have grown to the size we did. It is harder to build a technical services firm on a truly independent basis, relying only on relationships with buyers of technology. But it can be done, as my later experience at Strativa would show.

Lesson #3: True Management Consulting Requires Independence

This is a closely related lesson. During my entire time at the SI Firm managing implementation services teams, I continued my focus on ERP selection on the side. Then, in 1997, the owners asked me to form a management consulting practice focused on IT strategy, business strategy [7], and business process improvement. This, they hoped, would elevate our brand. Management consulting was always my top interest, and in a short time I hired a small team to help me. One of those was Dan Husiak, a Director of Business Process Reengineering and a Senior Consultant at Experian, who would later become my business partner and co-founder of Strativa.

But there was a conflict, on the IT strategy side, how could we do ERP selection consulting as part of a firm that was delivering services for four specific ERP systems? How could prospective clients be sure that our recommendations would not be biased toward those vendors where we had implementation practices? 

For some years previously, I threaded that needle by pointing to our references—all the times we had recommended, and clients had purchased, systems from vendors who were not our partners. But now a new problem arose. Our firm began reseller relationships with two of those vendors. Now there would be a strong incentive for our ERP selection work to favor those two vendors where we got sales commissions and where we could keep our implementation consultants busy. 

Sure enough, it didn’t take long before I started to feel pressure to have our ERP selection work favor those two vendors—to be fair, not from the owners but from other leaders within the firm. The financial incentives for a million-dollar software and implementation deal were much greater than the revenue we were receiving from the software selection engagement [8].

When Dan and I founded Strativa, we took this as a fundamental principle: No tech vendor partnerships. 

Lesson #4: Caring for Social Relationships in the Firm

I also learned during those eight years the importance of social relationships between team members. The owners were particularly strong on this aspect. Each summer we would have a 2.5 day team building retreat at some nearby resort, where we would meet around some business subjects or team building exercises and also have some social outings. 

This is not unusual, except for this aspect: The firm would also invite spouses or guests. It was not a small expense for the firm. But the owners thought it was too much to ask employees to leave their families for three days. Moreover, during the retreat the spouses/guests were also invited to all meetings, if they chose to attend. Some, like those on DiSC (behavioral) profiles, were quite interesting to many. The firm even paid for guests to get their own DiSC profiles. 

We would also have a holiday party at a nice restaurant each year, again, inviting spouses or guests. And the social events didn’t end there. At one point, Annie Roy, our technical services manager, arranged for us to take ballroom dance lessons, for those interested, including spouses and guests. 

As a result, I still know those family members of my coworkers. And interestingly, I don’t ever remember that we referred to the SI Firm as “a family.” Rather, the owners recognized and honored the fact that we all had families. We didn’t need the firm to be another family—which would have been awkward at the time layoffs became necessary. Who terminates family members?

When Dan and I founded Strativa, we continued this practice of caring for the social aspect. In the 20+ years that followed, we may not have held retreats, but we did have an annual holiday dinner and a summer barbeque, always including family members. Again, as a result, we got to know the families of our employees and never felt the need to refer to our firm as “a family” [9].

A Bridge in My Career Journey

I look back at those eight years at the SI Firm as a transitional period, from working as an independent consultant (a “single shingle”) to building and growing a consulting firm of some scale. In addition to the consulting lessons outlined above, I learned much about how to build and manage a consulting business. For example: 

  • Learning the keys to selling consulting services, which are intangible—something that prospects cannot touch or experience beforehand. 
  • Hiring, training, and retaining consultants—I developed an entire curriculum of consulting methodologies and consultant training, and I also designed the firm’s professional development planning process, which I separated from the traditional annual compensation review.
  • With the owners, designing incentive plans that reward high performers while protecting the firm on the downside.
  • Understanding labor law and compliance, including the structure of retirement profit-sharing plans. 
  • Accounting for the financial performance of the firm along with that of individual projects.
  • Developing the firm's first website in the mid-1990s—building web marketing skills that would serve us well in the coming decades. 

Without this experience, Dan and I would never have been able in 2000 to establish Strativa and in 2005 to acquire the IT research firm, Computer Economics. This experience includes the difficult times we all experienced in the final days of the SI Firm. As noted in an earlier post, adversity is often the catalyst for growth, whether personal or professional [10] [11].

End Notes

[1] I recently reconnected with VC and DM at a funeral of the wife of one of our coworkers. I later spent some time at DM's home catching up on the last 20+ years and filling in some blanks on what happened at the end of the SI Firm. I thank her for her insights. And I thank them both for giving me the opportunity to learn the lessons outlined in this post. 

[2] When I tell people I implemented a manufacturing system in the California state prisons, they usually respond, “What, for license plates?” Yes, those are produced in Folsom. But CALPIA’s manufacturing operations go far beyond license plates, producing a variety of foods, textiles, furniture, and other products. So, it was an interesting exercise to implement a single manufacturing system able to support such a wide variety of products and manufacturing processes. 

[3] Although they are not paid minimum wage, inmate job assignments were highly sought after, not just for the wages they earned, but also because they gave inmates something meaningful to do. In addition, they were learning skills they could take with them when they were released. There was a long waiting list. So, only the best-behaved inmates got these positions. I dealt with them directly, and I found some of them quite talented. In a women's prison, I found out later that one inmate had been a CFO. 

[4] Talk about “shadow IT!” In one prison, a group of inmates had developed and implemented a PC-based manufacturing control system. This was not a healthy situation because none of the free staff understood it and were totally reliant on the inmates. Compounding the problem, the inmates, with the approval of the free staff, had actually “exported” the system to another nearby prison, where it was maintained by another group of inmates there. One of our challenges was to displace this system with BPCS. But there was great organizational resistance to this. The inmates and the free staff together did not want to lose control. 

CALPIA Badges 1992 vs 2018
[5] I recall a time in another prison where I was delivering some BPCS training. The staff had set up workstations around the conference room table, with one inmate and one free staff member for each workstation. You would think it would be the free staff member helping the inmates understand how to use the keyboard. But in fact, it was the other way around! 

[6] There is an interesting postscript to this story. A few years ago, my team at Strativa got an invitation from another consultant to help him do an assessment of an ERP system at a California state agency. As it turns out, it was CALPIA. I told him, “You’re not going to believe this. I implemented that system there 25 years ago!” So, we returned to conduct the assessment. Since this was a more recent engagement, I won’t provide additional details, except to say there was one CALPIA employee who still remembered me from my time there 25 years previously. 

My CALPIA badges from 1992 and 2018 shown nearby show me then and now over those 26 years. Before 2001, I loved to use that 1992 badge to get me through airport security. I don’t recall ever having it rejected, even though it had long expired. I think it made me look like law enforcement. (The back side says, “State of California Department of Corrections” and is signed by a prison warden).  

[7] The business strategy side of our management consulting practice became impactful. For example, shortly after forming the group, we did a business strategy project for one of the largest health insurance providers in the U.S. at the time. I wrote about one experience there in this post: A Personal Experience of Lateral Thinking.

[8] I still see this happening today. Just recently, I learned of a major consulting firm that offered to do a strategy project at no charge if they also got the implementation services to carry out the strategy. Strategy projects nowadays almost always involve a technology aspect, and you can bet that the consulting firm will recommend their vendor partners in the proposed solution. For this reason, smart buyers require that if they hire a consulting firm to give technology advice, they will not be able to compete for the implementation work, and certainly not be the reseller of that technology product. 

[9] In the late 70s, Ray Hayes, a fellow manager in the IT department at Smith Tool, told me, “Frank, we’re not a family, we’re a team.” That sentence stuck with me all these years. Here’s a good post on the difference between a workplace family and a team. I realize that many business leaders who say their firm is a family do so innocently. But still, I think it best to avoid such language. 

[10] This post would not be complete without mentioning the professional connections and friendships I made at the SI Firm that became critical in my future business. One was John Simonelli, who was our CPA and later joined the firm as our General Manager. John became a dear friend and a business advisor to me and Dan in launching Strativa in 2000 and acquiring Computer Economics in 2005. After Dan’s death in 2008, John helped me greatly in acquiring Dan’s shares in the two companies, and in 2020 he was instrumental in advising me on the sale of the two firms to Avasant LLC. 

[11] At the risk of leaving someone out, there were many other relationships that continued under Strativa. These include Nick Hann, who joined us at Strativa as the first employee after me and Dan, staying with me through the acquisition of Strativa and retiring in 2022. Another is Dee Long, who joined us as a Strativa consultant and stayed through the acquisition. There is also Barbara Newton, who joined the SI Firm just after me and later joined us at Strativa and Computer Economics, helping me run those two firms for 20 years. Hugo Valldejuli contracted to us at Strativa and made a critical introduction that eventually led to our acquisition of Computer Economics. Lynn Drury joined us at Strativa as a project manager, and Bob Gilson joined us as a consulting practice leader. These all, and others from those years, remain personal friends. 

Friday, May 17, 2024

Generative AI: Not Ready for Stand Up

Fortune Cookie
One of my favorite tools for generative AI is Meta AI. I like that it is quick and convenient to access via WhatsApp, its answers are generally useful, and it often gives references that I can use for verification or citation. 

That said, Meta AI, like all large language models, suffers from a lack of creativity. This is not surprising, because LLMs have been trained on existing content. They are good at summarization, classification, and categorization. But they will not and cannot come up with something new or unique. 

As a result, they don’t write interesting fiction. They are painfully bad at poetry and song lyrics. And, as we’ll see in a moment, they’re not good at writing jokes. At most, they can trigger ideas for you that you might be able to take as a starting point. But don’t expect to be able to copy/paste. 

So, on a whim last night, while watching TV, I did an experiment with Meta AI. Here are my prompts with its responses.  See if you agree that comedy writers should not be worried about losing their jobs to generative AI, at least not yet.

Me: Give me five humorous fortune cookies.

Meta AI: Here are five humorous fortune cookies: 

"You will soon find yourself on a new adventure. Hopefully, it's not a trip to the dentist."
"Good news: you're about to meet someone special. Bad news: it's your in-laws."
"You are destined for greatness. Or, at the very least, a decent Netflix binge-watching session."
"Your future is filled with wealth and success. Just kidding, it's probably just bills and laundry."
"You will soon find true love. Until then, Tinder will have to do."

I hope these made you chuckle!

Those are pretty bad.

Meta AI: I see you're a tough crowd! Humor can be subjective, and I apologize if my previous attempts didn't quite hit the mark. Let me try again with a fresh batch of humorous fortune cookies: 

"You're about to have a brilliant idea. Unfortunately, it's already patented by a genius named Steve."
"Your future is filled with endless possibilities. And by 'endless possibilities,' I mean Netflix recommendations."
"You're on the path to greatness. Just don't forget to wear comfy shoes."
"A new opportunity is coming your way. Hopefully, it's not a timeshare presentation."
"Your luck is about to change. But don't worry, it's not like you'll win the lottery or anything... unless you actually play."

If these don't bring a smile, I'll keep trying!

How about, “People love you, in spite of your table manners.” 

That's a great one! You're absolutely right, that one is funny! I should have thought of that one. "People love you, in spite of your table manners" is a hilarious and relatable fortune cookie message. It's a lighthearted way to poke fun at someone's potentially questionable table etiquette, while also acknowledging that they're still loved and appreciated despite their flaws. Well done! You've set the bar high for me now!

You don’t need to explain so much. Either you get it, or you don’t.

You're right! I sometimes provide more context than necessary. I'll keep it in mind to be more concise in my responses. If you get it, great! If not, I'll try again or move on. Thanks for the feedback!

How about “You coulda been a contender?”

Another great one! "You coulda been a contender" is a classic phrase that's both humorous and slightly sarcastic. It's a playful way to poke fun at someone's potential, implying that they might have achieved greatness if only they'd tried a bit harder. It's a clever and amusing fortune cookie message!

Do you know where that quote is from?

The quote "I coulda been a contender" is from the 1954 movie "On the Waterfront," directed by Elia Kazan and starring Marlon Brando, Eva Marie Saint, Rod Steiger and Karl Malden ¹. The line is spoken by Brando's character, Terry Malloy, a former boxer turned longshoreman, to his brother Charley (Steiger) [references omitted]

Yes. That’s what makes it funny.

Exactly! The quote's origins in a dramatic and iconic movie scene add to the humor when used in a more lighthearted context like a fortune cookie message. It's a clever play on expectations, using a famous line from a serious movie in a humorous way. The unexpected twist creates the comedic effect!

Keep your day job.

Haha, fair enough! I won't quit my day job as a Meta AI assistant just yet. But I appreciate your honest feedback and will keep working to improve my humor and wit. Maybe one day I'll be able to come up with a fortune cookie message that makes you laugh out loud!


Have a different point of view?  Feel free to leave a comment. 

Tuesday, December 26, 2023

Three Decades of Software Vendor Selection

Traffic sign: Fork in the road
This post continues my series on lessons learned in my career. Chronologically, we left off with my work on a major system development project at Smith Tool. By the time I finished, I had been an independent consultant for about six years. But during that time, I also began to branch out to other clients. These included travelling around the US and beyond, doing mainframe conversion training, 4GL software development, and other consulting engagements.

All these clients had one thing in common. They all came directly or indirectly by referrals from former coworkers at Smith. As it turns out, I was lucky. When a sole proprietor, like me at this time, is busy with project work, it is difficult to develop new opportunities. And when a project ends, it is not easy to develop a new opportunity on short notice. Those independent consultants I know who have been successful over many years generally have reputations as experts. They also tend to have multiple revenue streams in addition to their consulting work, such as paid speaking engagements, books, or paid media contributions. Balancing project work with business development is easier for a consulting firm with some scale, something I would learn later in my career.

But in 1989, there was still one more referral for me. A former coworker from Smith Tool, Rick McGough, had just been hired as the top IT executive for Toshiba America Medical Systems (TAMS) [1]. TAMS was the U.S. distribution and field services unit for Toshiba’s medical diagnostic imaging device business [2]. Rick was looking to replace a homegrown business management system with a commercial ERP system. TAMS already had two Deloitte consultants on the project [3], but Rick wanted “his own guy” on the project team as well. So, he brought me in. This would my first real exposure to a full-blown ERP selection project, and this was the basis for my continuing this type of work over the following three decades, evaluating and selecting all manner of software, including ERP, but CRM, HCM, supply chain, and other categories of enterprise systems.

Lesson #1: Focus on Differentiators

The Deloitte consultants had recycled a requirements document of several hundred pages from a previous client and attempted to modify it for use at Toshiba. This turned out not to be a great approach, as the document included a number of requirements that didn’t apply to TAMS, and it missed several important requirements.

One key requirement was serial number tracking, which is an FDA regulatory mandate. Each unit of equipment and even critical components within a finished assembly need to be tracked with a unique identifier. So, if Toshiba receives 10 X-ray tubes from Japan, it’s not enough just to record a receipt of 10 units. It must record the serial numbers of those 10 units and track them in inventory and through distribution to the installed customer base. But guess what. The system that the team ultimately chose (BPCS from System Software Associates, or SSA) did not have serial number tracking. It did have lot number tracking, and the reseller’s proposed solution was to use the lot number as the serial number and modify the source code to force a lot quantity of one. They also had to do a modification to the inventory receipt program to allow the data entry user to enter the individual serial numbers at time of receipt. As you can imagine, there were other modifications needed for inventory management, sales, and distribution to accommodate the “lot number as serial number modification.”

To make a long story short, this was an example of a requirement that was so important that it normally should have disqualified that vendor from consideration [4]. I now call these types of requirements “differentiators.” They are more than priority A. They are show-stoppers. As a result, BPCS did not last long at Toshiba. It was replaced a few years later by Oracle Applications (today, E-Business Suite), which could satisfy the serial number tracking requirement as well as other differentiators.

Based on this lesson learned, I made a practice of identifying five to 10 differentiators for the client. I would use that to qualify vendors for the initial short list. In developing a short list, you really don’t need an RFP with hundreds or thousands of requirements. But you do need to know these key criteria. You can specify additional requirements (though I recommend avoiding hundreds) later in the selection process. Over the years, I had other experiences where the client made a vendor selection decision without following this best practice [5].

Lesson #2: If You Must Modify, Do It with Bolt-on Modifications

Another concept I developed during this project was the difference between good modifications and bad modifications. I recall standing at a whiteboard, discussing this with the Deloitte consultants. I told them we should avoid customizing vendor source code. The reason is that it may disrupt the logical integrity of the system—it may break the system in unanticipated ways. Second, it makes it difficult to upgrade to new releases of the software, because all those customizations will need to be carried forward to the new version.

Instead of customizing the vendor’s source code, I said that we should develop what I called “bolt-on modifications.” I drew a diagram on the white board, showing the modifications as a separate program or subsystem external to the vendor’s code, and calling it by means of an API. This approach is common today in what is known as a service-oriented, modular, or composable architecture [6].

Sadly, the modification to the lot number logic I mentioned in the previous lesson could not be accomplished with a bolt-on modification. It required modification of the core source code. As a result, it took the project team six months shortly after the initial implementation to do an upgrade to the next version.

Lesson #3: ERP Can Be Hard to Justify with Tangible Benefits

An ERP implementation is a major expenditure, and as such it would need management approval in the form of a capital expenditure request, which would need to budget both the costs and the anticipated benefits. The cost side of the equation is usually easy—hardware, software, and implementation costs could all be estimated based on vendor proposals.

The benefits side, however, is more difficult, especially if you want to identify tangible benefits. The project team for improvements in inventory accuracy, order fill rates, customer service improvements, and other areas. Time and again, we would identify a possible improvement but would conclude, “it doesn’t move the needle” [7]. Later in my career, our research at Computer Economics confirmed this finding [8].

When there are tangible benefits, they are mostly in two areas:
  • Productivity savings. If the organization required 15 accounts payable personnel and the new system could cut that number to 10, that would be a productivity improvement. But few organizations really want to bank on that—they hate to lay off people. They would rather redeploy them into other roles. Or, they would rather say that the new system could allow future growth without adding to administrative headcount.
  • Discontinuation of legacy systems. If the new system is replacing an old system—and preferably several old systems, there will be savings in the hardware, software, and personnel that supported the old system. If the system was highly modified, the new system might require fewer personnel, although this is often not the case, especially in the early years.
Therefore, in selection projects over the years, I’ve concluded that ERP benefits are mostly intangible—difficult to put a dollar value on. If done right, they give management better data to support decision-making, and they provide a single source of truth. Most importantly, they provide a better platform for future systems that rely on ERP data, such as business intelligence. There are also other more strategic drivers: the old system might no longer be supported by the vendor, or it might be on a legacy hardware platform. I’ve seen more situations where this was the driving force for a system replacement than I have with a business case based on tangible benefits [9].

Lesson #4: Software Selection Is More Than Selecting Software

But the greatest lesson learned from this first selection project and over the following three decades is that software selection projects are really mis-named. They are not just about selecting software—they are about business transformation. As such, there are some key success factors:
  • Business sponsorship. Just because computers are involved does not make these projects computer projects. They should be driven by the business, with the IT organization as part of the project team. Top management should actively sponsor the project and not delegate it to middle management.
  • Strategic alignment. Many ERP selections arise from organizations changing their business model, acquiring new lines of business, or expanding into new markets. To provide context, ERP selection should start with a review of the current and future business strategy and how IT is aligned to support it.
  • Application portfolio rationalization. Many clients have dozens of enterprise systems, and many of them are inter-connected. When replacing a major system, should those other systems stay or go? Most organizations would do well to first address the entire portfolio of applications and lay out a strategic road map to understand which should be replaced or consolidated.
  • IT organizational impact. Does the current IT organization have the needed skills to support the future applications road map, including the new system? If not, what new skills are needed and how should the IT staff be organized?
  • System integrator selection. Selecting the new software is not the only decision. Most organizations will need to select an ERP implementation partner. Having the right ERP system but the wrong implementation partner often leads to failure. In fact, some of my projects over the next 30+ years involved finding a new implementation partner to replace the one that failed.
  • Client-side planning. Generally, the system integrator will have a good handle on what it needs to do. But the client’s project team must also plan for the activities required on the client side, such as training, data conversion, procedure writing, and acceptance testing. The system integrator will generally expect the client to be responsible for these activities.
  • Business process improvement. New systems can involve major changes in business processes--hopefully for the better. The selection team should also anticipate what business process improvement will be needed as part of the new system and include those in the project plan.
  • Change management. Enterprise software implementations rarely fail because of technology problems (though, it does happen). They often fail because of organizational resistance to change. Engaging the organization during new system selection is how you gain buy in for the decision, setting the stage for cooperation during the implementation.

Further Industry Specialization

I look back at my experience with Toshiba as a major steppingstone in my career. As was my habit, once again, I immersed myself in the business—in this case medical devices. I interviewed business leaders and studied the various imaging system modalities, such as X-ray, MRI, CT, and ultrasound. Short term, this enabled me to continue consulting for Toshiba on the business side after the implementation was finished. I moved into the customer service group, defining requirements for future field service systems. Longer term, my experience at Toshiba became a foundation for my later industry focus on medical devices and life sciences in general, including FDA regulatory compliance.

Photo credit: Frank Scavo.   

End Notes

[1] Rick had had been hired at Smith Tool as a programmer analyst in 1978, about the same time I was. But whereas I took a career path to get deeper into the business, eventually leaving the IT department, Rick chose an IT management path. He rose through the ranks eventually becoming the IT director. As noted in an earlier post, the 1980s were a tumultuous time for Smith, and in 1989 Rick left to take the top IT job at Toshiba. He is now retired after holding several senior IT positions at other firms.

[2] Toshiba Medical was acquired by Canon in 2016 and is now Canon Medical Systems Corp. The US headquarters is still located just a few miles from where we lived at the time.

[3] One of those two Deloitte consultants was John Olszewski. John became a good friend, and we worked together on and off for something like six to eight years for other clients. He continued with Toshiba long after my work there was completed. He eventually played a leading role in replacing BPCS with Oracle Applications. With that experience, he then went to work for Oracle, where he is now Senior Director E-Business Suite Service Product Management.

[4] There was one key requirement that tipped the scales in favor of BPCS and that was its ability to specify sales features and options in a multi-level planning bill of material. None of the other systems on our short list, which Toshiba had restricted to IBM midrange systems, could satisfy that requirement.

[5] Several years later, I had another client where the chosen vendor did not satisfy a show-stopper. Coincidentally, John Olszewski and I worked together on this project. We came in after the vendor selection to help with the implementation. Here the client was a well-known multi-level marketing (MLM) company. In this industry, customers (i.e., independent distributors) would deposit cash into their accounts against which they would place orders for their customers. The MLM company would then fulfill those orders. In other words, the independent distributors had to pay in advance. But the chosen system was a typical B2B system. It assumed the independent distributor would place an order, and then the MLM company would fulfill it, invoice the distributor, collect the payment, and apply it to the invoice. As a result, we had to modify the system to accommodate this fundamental process misalignment. In retrospect, this system should have been dropped from consideration just based on this one showstopper.

[6] The term “bolt-on modification” is in common use today, but I am convinced that I invented the term. I have searched and have not been able to find a reference to the use of this metaphor prior to 1989. Yes, it was used in the automotive industry, but I can’t find anyone using it relative to software engineering. If anyone can find it, I will be happy to give up my claim. But until then, I am claiming authorship.

[7] As in the previous note, I’m convinced that I coined the phrase, “it doesn’t move the needle.” In trying to come up with the business case, I used it as shorthand for, “Yes, that may be a benefit, but it is too small to really make a difference.” I had in mind an automobile fuel gage where adding a small amount of fuel would not be enough to make the needle move. Again, I have not been able to find use of this term as a metaphor prior to 1989. But I’m willing to see evidence otherwise.

[8] Our research at Computer Economics (now part of Avasant) over the years compared the ROI and TCO experience of a number of IT investments. We found consistently that ERP ranked dead last in economic success. We argue that this does not mean organizations should not invest in ERP, but rather that the benefits on the one hand can be difficult to quantify and that the costs need to be carefully controlled to stay within budget.

[9] What about growth in revenue? In my experience, it is difficult to claim top line benefits from ERP systems, which are mainly focused on back office processes. If a new ERP system is needed to support a new line of business, there would be top line benefits, of course, but the contribution of ERP is indirectly tied to that outcome. CRM systems on the other hand might be justified in terms of improved customer service, improved upsell/cross-sell performance and other measures that increase revenue. 

Thursday, November 02, 2023

Generative AI and the New Data-Driven Productivity Paradigm

Earlier this week, I led an Avasant panel discussion on Generative AI and the New Data-Driven Productivity Paradigm. You can watch the entire video here. 

I started with a brief introduction to set the stage, comparing today's generative AI (GenAI) services with earlier forms of AI, which date back several decades. The panel then discussed a number of important elements of generative AI: 

  • Why GenAI has gotten so much attention over the past year. 
  • Where we see GenAI delivering productivity gains as well as top line revenue growth. 
  • Data quality as a prerequisite for realizing GenAI benefits as well as issues around confidentiality and data privacy. 
  • The regulatory landscape around GenAI, even today with GDPR as well as in the future. 
  • The enterprise risks for enterprises to consider in implementing GenAI systems. 

We ended with a lightning round about practical steps for organizations to take in getting started with GenAI. 

What is Generative AI?
What is Generative AI?

Tuesday, August 29, 2023

Opportunities and Challenges with Generative AI

Although artificial intelligence originated in academic research in the 1950s, only recently has it captured the imagination of the general public. This has everything to do with the release of ChatGPT, which putg a powerful generative AI tool in the hands of individual consumers. But what are the opportunities it brings to businesses? And what are the challenges we face in using it?

I blogged about this back in February, not long after ChatGPT was released, in my post, ChatGPT for Industry Research: Not Ready for Prime Time. This was based on my early testing of the technology. Since that time, use cases by industry have started to surface, and there are many promising opportunities, just a few of which we discuss in my interview. But the risks and concerns still remain. How can we realize the opportunities, while minimizing the risks?

Read a summary of the interview on the Avasant website with the link to the full video.

Frank Scavo video interview on generative AI

Monday, August 21, 2023

A Teams Model for Effective Innovation

This post continues my series on lessons learned in my career, the ideas that influenced me, and the people who helped me along the way. This post is on the role of teams in developing and implementing innovation.

Most of my career as a consultant over the past 40+ years has involved innovation in one way or another. That’s what originally drew me into consulting. But innovation is rarely the domain of individual contributors. Innovation is a team sport. The most interesting and exciting times in my career have been when I could participate in a team focused on some sort of innovation. These experiences included developing new systems, building several consulting practices, developing new research publications, or participating as a consultant on a client’s team. 

So, it is critical to understand how team members can work together most effectively to bring an idea to reality. And this includes understanding the roles that each innovation team requires and the stages that the team passes through. 

Two Conceptual Models for Working Together

For most of the 1990s, I was a consultant for a systems integration firm in Orange County, California (no longer in business). During that time, I first managed two groups of ERP implementation consultants and then launched a management consulting practice within the firm. I also developed most of the firm’s internal training and consulting methodologies. Because the owners of the firm knew how important teaming was to our success, they brought in an outside consultant, Dr. Karol A. Bailey, to train us in two behavioral profiling tools. 

  • The first was DiSC, an assessment tool to help individuals better understand themselves and others, along with their preferred work styles. Originating in research from the 1920s, DiSC has gone through multiple iterations and refinements over the years and is still in widespread use today. It is now owned by John Wiley & Sons and is available through its authorized resellers. It is a powerful tool, and I still apply it today in my personal interactions and collaboration with others. My long-time associate Dee Long became a certified DiSC trainer and has been a great help to me in continuing to apply it over the past three decades. 
  • The second was what we knew, at the time, as the C.A.R.E. profile [1]. Although this model is synergistic with DiSC, it was developed independently. It specifically focuses on the roles that are needed in any team and the stages that an innovation should go through to successful implementation. 

The C.A.R.E model is illustrated in the schematic below, which I’ve drawn from memory and earlier training material. It recognizes that a successful team moves an idea through four distinct phases, in sequence, forming a Z-pattern.  

CARE model of teams
Click to enlarge

  1. Creators. These are the idea people, who dream of new possibilities. They often start sentences with, “Wouldn’t it be great if ___________”. 
  2. Advancers. These are those who take the idea and run with it, communicating and promoting it inside and outside the team. Through interactions with others, they test the idea to see if there is—or could be—a market for it. 
  3. Refiners. These are those who analyze the idea to find issues or problems that stand in the way of success and develop solutions resolve the problems. 
  4. Executors. These are the team members who oversee the implementation and, if appropriate, support it on an ongoing basis. 

The two roles on the top—Creator and Advancer—are focused on possibilities, what could be. They have their heads in the clouds. The roles on the bottom—Refiner and Executor—are focused on realities, what is practical. They have their feet firmly planted on the ground. The two roles on the left—Creator and Refiner—are focused on analysis. They like to work with abstract ideas. The two roles on the right—Advancer and Executor—are focused on relationships. They like to work with people.

The C.A.R.E model also recognizes a fifth profile, the Flexer. This is the least common profile. These are individuals who by nature can serve in any of the other four roles. They are like utility players in baseball, able to play any position. They are also good at facilitating the process of moving the innovation from one stage to the next in the Z-process. You don’t need to have a flexer on your team, but if you have one it can be quite valuable. 

Moving Through the Four Stages

It is important to realize that to ensure success, any innovation must pass through these four stages, and skipping over a stage will lead to failure. For example: 

  1. Jumping straight from creation to execution. Some creators are so excited about the idea that they want to implement it immediately. “Let’s just do it!” they exclaim. Organizations with this culture tend to launch many new initiatives, most of which wither like flowers without water. 
  2. Skipping the Advancer stage. This sometimes happens when the Refiners look at the new idea and immediately see problems with it. They look at the Advancers as cheerleaders, not realistic about what it will take to make the idea work. They don’t realize that someone first needs to communicate and promote the idea, to see if there really is a market for it. Without advancers, the idea suffers “paralysis by analysis.” Refiners by nature wear what Ed De Bono called the black hat (seeing the negative). First the idea needs some promotion, for team members to put on what De Bono called the yellow hat (seeing the positive).  
  3. Skipping the Refiner stage. This happens when the Advancer stage shows the idea has legs and has good possibilities. The team gets excited and wants to move straight into execution. But without analyzing the idea and resolving any issues the innovation will likely fail in execution. Few ideas are perfect in their initial conception. Some refinement is almost always needed. It is like the testing phase in software development. No system can go straight from development to production. It is important to see Refiners not as naysayers but having an important role to play in perfecting the innovation so the idea will succeed. 
  4. Not following through to execution. This happens when the team does not have many hands-on doers. It is an even greater problem when the idea is a product or service that needs ongoing support and management. Organizations like consulting firms that are mostly project-based businesses can have this problem. They are good at managing projects that have a beginning and an ending with a defined set of deliverables. But they may not have many people with skills and process-orientation to manage something day in and day out. 

Even if a person is not assessed as a Flexer, he or she may be comfortable in more than one role. Many team members will have a preferred role while also gravitating toward a second role. One common combination is Creator/Advancer—those who come up with new ideas and are also good at promoting them to others.  Another is Creator/Refiner—those who are good at conceiving new ideas and also good at perfecting them. Another is Refiner/Executor—those who refine the idea and then implement and manage it going forward. 

My Preferred Role

So, how did I test out? I am a Creator/Refiner. I love coming up with new ideas, and I am also good at analyzing them and refining them to make them better. At the same time, I may not be the best person to advance an idea. In fact, the Refiner-side of my profile means I tend to get nervous when the team rushes to promote an idea (especially if it wasn’t my idea!). As an analytical person, I tend to see the problems, the defects. So, I need to remind myself that ideas need to be promoted before they can be refined. There is a time for promoting and a time for refining. 

I am also not natural as an Executor. Of course, having owned two businesses for twenty years, I could not avoid ongoing operations. But I have always done my best when I had team members that were good at execution, with an attention to detail so I could do what I do best. Fortunately, I was blessed over many years to have had a few business associates who were excellent as Executors [2][3]. 

Although the original C.A.R.E assessment is no longer in commercial distribution, it is not difficult for individuals to figure out what roles they prefer to play. The important thing is for the entire team to understand the four roles and to move an innovation idea through these four stages. This will lead to greater appreciation for others and their unique contributions to team success. 

End Notes

[1] The C.A.R.E assessment was later rebranded as Team Dimensions, which, like DiSC, is also owned by Wiley. Although Wiley no longer markets it, it may be available in different forms through other providers.

[2] One was Barbara Newton, whom I’ve known for 30 years. She worked with me and Dee Long at that systems integration firm I mentioned earlier. She then joined my partner and I when we launched the consulting firm Strativa in 2000 and later acquired Computer Economics in 2005. She was responsible for all of the research publication processes as well as client services. She stayed on through our acquisition by Avasant in 2020 and retired in 2021. 

[3] Another example is Sherry Maples, who joined us in 2001 and stayed on for nearly 20 years. She ran the accounting function and, with Barbara, managed the back-office processes for the two companies, freeing me to focus on consulting and research. She retired in 2019. She was incredibly detailed oriented, which is exactly what I needed in those years. 

Tuesday, February 14, 2023

ChatGPT for Industry Research: Not Ready for Prime Time

ChatGPT: Four Errors in a Single Sentence
Since its unveiling in November 2022, there has been a lot of buzz around ChatGPT—OpenAI’s generative AI chatbot. Although there are similar projects, such as Google’s Bard, ChatGPT got an enormous boost as it was free, easy to use, and could be deployed in a variety of ways—from answering questions to writing essays, poems, and song lyrics, to coming up with recipes, to writing software code, based on simple prompts from the user. 

One inevitable question of course was, to what extent would ChatGPT threaten jobs?

For me, it’s an important question. I direct a team of IT and industry research analysts at Avasant. Is ChatGPT a disruptive threat to our business? Would competitors, with less-skilled workers, be able to generate research as good or in greater quantities than what we could produce? Would clients even need research firms like ours at all, if they could generate their own reports, using these tools? Or, can we leverage a tool like ChatGPT to make us more productive? 

Putting ChatGPT to the Test

To find out, I did a series of tests to see if ChatGPT could write a short research note. 

One of my tests was to ask ChatGPT to write about something I am intimately familiar with: The history of the IT research firm Computer Economics, which my partner and I acquired in 2005 and I sold to Avasant in 2020. (I still manage this business as part of Avasant Research.) 

Here is the transcript of my prompts and the responses from ChatGPT, lightly edited for length, along with my evaluation of ChatGPT. 

Prompt: “Provide a history of the IT research firm Computer Economics.”

ChatGPT responded: 

Computer Economics is a research and consulting firm specializing in the field of information technology (IT). The company was founded in 1982 in Newport Beach, California, by John L_________, who currently serves as the firm's President and CEO. 

There are four factual errors in the second sentence of this opening paragraph! Computer Economics was founded in 1979, not 1982, as documented in this Wikipedia entry. (Wikipedia is a primary source for ChatGPT's training data, so how did it miss this?) Moreover, the firm was founded in New York City, not Newport Beach, by Bruno Bassi, not John L., and John L. was never the company president. He was our VP of Research, from 2007 until he retired in 2017. ChatGPT just made this all up. 

But wait, there's more! A couple of paragraphs later, ChatGPT writes: 

Computer Economics … has received several awards for its work, including recognition from Forrester Research as a “Leading IT Research and Advisory Firm” and from Gartner as a “Top IT Research and Consulting Firm.” 

But neither Forrester nor Gartner has any such award program. In fact, it would be hilarious if they did since they are both IT research and consulting/advisory firms themselves! ChatGPT just made up that part. So, I gave ChatGPT another prompt and a chance to correct itself. 

Prompt: “Please provide more information about Gartner's award program for Top IT Research and Consulting firms. When was this program established and who were some of the most recent winners of this award?” 

ChatGPT responded (click to enlarge): 

ChatGPT Hallucinations
ChatGPT Hallucinations

Apparently, ChatGPT is not aware of the First Law of Holes: When you find yourself in one, stop digging. 

My prompt asked who some recent award winners were. Now it says the winners are not publicly available. What kind of award keeps the winners secret? Moreover, if the winners are secret, how does it know Computer Economics was one of them? At the same time, the winners must not be secret, because they “can be found in Gartner’s annual report on the market for IT research and consulting services” (which, of course, does not exist).

Risks in the Use of ChatGPT for Research

In summary, here are some observations on the risks of using ChatGPT as a virtual research analyst.  

  1. Fiction parading as fact. As shown above, ChatGPT is prone to simply make up stuff. When it does, it declares it with confidence—what some have called hallucinations. Whatever savings a research firm might gain in analyst productivity it might lose in fact-checking since you can’t trust anything it says. If ChatGPT says the sun rises in the east, you might want to go outside tomorrow morning to double-check it.  
  2. Lack of citations. Fiction parading as fact might not be so bad if ChatGPT would cite its sources, but it refuses to say where it got its information, even when asked to do so. In AI terms, it violates the four principles of explainability
  3. Risk of plagiarism. Lack of citations means you can never be sure if ChatGPT is committing plagiarism. It never uses direct quotes, so it most likely is paraphrasing from one or multiple sources. But this can be difficult to spot. More concerning, it might be copying an original idea or insight from some other author, opening the door to the misappropriation of copyrighted material. 

Possible Limited Uses for ChatGPT

We are still in the early days of generative AI, and it will no doubt get better in the coming years. So, perhaps there may be some limited uses for ChatGPT in writing research. Here are two ideas. 

The first use might be simply to help overcome writer’s block. We all know what it’s like to start with a blank sheet of paper. ChatGPT might be able to offer a starting point for a blog post or research note, especially for the introduction, which the analyst could then refine. 

An additional use case might be to use ChatGPT to help come up with a structure for a research note. To test this, I thought about writing a blog post on the recent layoffs in the tech industry. I had some ideas on what to write but wanted to see if ChatGPT could come up with a coherent structure. So, I gave it a list of tech companies that had recently announced layoffs. Then I gave it some additional prompts: 

  • What do these companies have in common? Or are the reasons for the layoffs different for some of them? 
  • As a counterpoint, include some examples of tech companies that are hiring.
  • Talk about how these layoffs go against the concept of a company being a family. Families do not lay off family members when times are tight. 
  • Point out that many employees in the tech industry have never experienced a downturn and this is something that they are not used to dealing with.

The result was not bad. With a little editing, rearranging, and rewriting it could make a passable piece of news analysis. As noted earlier, however, the results would need to be carefully fact-checked, and citations might need to be added. 

One word of warning, however: In order to learn, young writers need to struggle a little, whether it is by having to stare at a blank sheet of paper or constructing a narrative. I am concerned that the overuse of tools like ChatGPT could deny junior analysts the experience they need to learn to write and think for themselves. 

The larger lesson here is that you can’t just ask ChatGPT to come up with a research note on its own. You must have an idea and a point of view and give ChatGPT something to work with. In other words, treat ChatGPT as a research assistant. You still need to be the analyst, and you need to make the work product your own. 

I will be experimenting more with ChatGPT in the near future. Hopefully, improvements in the tool will mitigate the problems and risks.


Update Feb. 20, 2023: Jon Reed has posted two lengthy comments on this post with good feedback. Check them out below in the comments section. 

Sunday, October 09, 2022

What If You Held a Metaverse Party and Nobody Came?

The metaverse just might be the next big thing, but according to two reports this week, that time is not yet. 

The first story is from CoinDesk, which reports that the two leading decentralized metaverse platforms--Decentraland and The Sandbox average below 1,000 daily users. Yet each is a unicorn, with over $1 billion in valuation. 

What’s going on in the metaverse these days, you might ask. Looking at two of the biggest companies with over $1 billion valuations, the answer is surprising: Not much, or at least not enough to bring users back every day. According to data from DappRadar, the Ethereum-based virtual world Decentraland had 38 active users in the past 24 hours, while competitor The Sandbox boasted 522 active users in that same time.

An active user, according to DappRadar, is defined as a unique wallet address' interaction with the platform’s smart contract.

This matches my own observation a few weeks ago when I created an account on Decentraland. Apart from the clunky graphics, the thing that struck me was, there's no one here! Until I read the CoinDesk report, I thought maybe I was doing it wrong. But apparently not.  

So, maybe the centralized metaverse platforms, such as the Meta (formerly Facebook) Horizon Worlds platform, is where the action is.  Apparently not. According to this report on The Verge, the user experience on Horizon Worlds is so bad that management under Mark Zuckerberg has to encourage, cajole, and beg even its metaverse developers to use it.   

In a follow-up memo dated September 30th, Shah said that employees still weren’t using Horizon enough, writing that a plan was being made to “hold managers accountable” for having their teams use Horizon at least once a week. “Everyone in this organization should make it their mission to fall in love with Horizon Worlds. You can’t do that without using it. Get in there. Organize times to do it with your colleagues or friends, in both internal builds but also the public build so you can interact with our community.”

On the other hand, we are already seeing real value in some early metaverse business applications. Two weeks ago, I co-moderated a metaverse panel discussion at Innovate@UCLA. One of the panelists, Chris Mattmann, Chief Technology and Innovation Officer at Jet Propulsion Laboratory described how JPL is already using metaverse-like digital worlds to great success for employee onboarding, virtual tours, and virtual meetings.  

Early adopters, like JPL, give an indication of where the value may lie. But for now, as far as public metaverse platforms go, it appears we are close to or at the peak of the hype cycle. 

On the third hand, I’ve been wrong before. As I wrote earlier this year: Predictions are hard, especially about the future.


Image Credit: Decentraland, via CoinDesk. 

Sunday, August 07, 2022

An Innovator’s Story: Creating a Business for Lasting Success

Back in May, I had the opportunity to do an on-stage interview with Jamie Siminoff, founder and CEO of Ring, as part of Avasant's Empowering Beyond Summit

Ring, the first provider of video doorbells, is an interesting case study in innovation. Siminoff founded the firm in 2013, and, despite walking away from an episode of Shark Tank with no money, grew it to disrupt the home security industry.

Siminoff eventually sold Ring to Amazon in 2018 for over $1 billion. Now, under Amazon’s ownership, he continues to manage Ring, which has grown to be the largest home security camera brand in the world.

Over on the Avasant website, I put together a summary of  Siminoff’s keynote and my on-stage interview around two broad themes:

  • Lessons learned in innovation, based on Ring’s invention. 
  • How to ensure success when an innovative startup is acquired by a much larger enterprise.

The research byte concludes with Siminoff’s view on how business leaders in traditional organizations can apply the lessons in innovation.

Read the research byte on the Avasant website: An Innovator’s Story: Creating a Business for Lasting Success