tag:blogger.com,1999:blog-35110562024-03-26T23:37:59.895-07:00The Enterprise SpectatorSince 2002, providing independent analysis of issues and trends in enterprise technology with a critical analysis of the marketplace.Unknownnoreply@blogger.comBlogger983125tag:blogger.com,1999:blog-3511056.post-42174229297576556182023-12-26T13:52:00.000-08:002024-02-01T07:49:06.073-08:00Three Decades of Software Vendor Selection<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjizeW72sIUl3lxU3bb1xFpeR5ZDilr6hCEEVjuBtqYr8ZNbN0-5YVd6uK0QZKMJGrw7J6AKEpLShRpBKCVZc-TmwbUT_N8D49li9fRJfdTC406ROjdMehLqGelJAkJmIMUR5xbZPn3bmlFULgnmcu62D52eCVHXli4uM_tdwJqNqnuVMPcX5ta/s286/ChoicePath.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="Traffic sign: Fork in the road" border="0" data-original-height="203" data-original-width="286" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjizeW72sIUl3lxU3bb1xFpeR5ZDilr6hCEEVjuBtqYr8ZNbN0-5YVd6uK0QZKMJGrw7J6AKEpLShRpBKCVZc-TmwbUT_N8D49li9fRJfdTC406ROjdMehLqGelJAkJmIMUR5xbZPn3bmlFULgnmcu62D52eCVHXli4uM_tdwJqNqnuVMPcX5ta/s16000/ChoicePath.png" /></a></div>This post continues my series on lessons learned in my career. Chronologically, we left off with my work on a <a href="https://fscavo.blogspot.com/2022/04/the-most-significant-system-development.html">major system development project at Smith Tool</a>. 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.<br /><br />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. <br /><br />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.<h3 style="text-align: left;">Lesson #1: Focus on Differentiators</h3><div>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. <br /><br />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.” <br /><br />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. <br /><br />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].</div><div><h3 style="text-align: left;">Lesson #2: If You Must Modify, Do It with Bolt-on Modifications </h3>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. <br /><br />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]. <br /><br />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. <br /><h3 style="text-align: left;">Lesson #3: ERP Can Be Hard to Justify with Tangible Benefits </h3>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. <br /><br />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]. <br /><br />When there are tangible benefits, they are mostly in two areas:<br /><ul style="text-align: left;"><li><b>Productivity savings.</b> 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.</li><li><b>Discontinuation of legacy systems</b>. 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. </li></ul>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].<br /><h3 style="text-align: left;">Lesson #4: Software Selection Is More Than Selecting Software </h3>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: <br /><ul style="text-align: left;"><li><b>Business sponsorship. </b>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.</li><li><b>Strategic alignment</b>. 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. </li><li><b>Application portfolio rationalization.</b> 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.</li><li><b>IT organizational impact.</b> 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? </li><li><b>System integrator selection.</b> 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. </li><li><b>Client-side planning.</b> 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. </li><li><b>Business process improvement</b>. 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. </li><li><b>Change management.</b> 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. </li></ul><h3 style="text-align: left;">Further Industry Specialization </h3>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.</div><div><br /></div><div><i>Photo credit: Frank Scavo. </i> <br /><h3 style="text-align: left;">End Notes </h3>[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. <br /><br />[2] Toshiba Medical was acquired by Canon in 2016 and is now <a href="https://us.medical.canon/about/">Canon Medical Systems Corp</a>. The US headquarters is still located just a few miles from where we lived at the time. <br /><br />[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 <a href="https://www.linkedin.com/in/john-olszewski-b3998/">Senior Director E-Business Suite Service Product Management</a>. <br /><br />[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. <br /><br />[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. <br /><br />[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. <br /><br />[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. <br /><br />[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 <a href="https://avasant.com/report/erp-dead-last-again/">ERP ranked dead last</a> 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.<br /><br /></div><div>[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. <br /><div><br /></div></div>Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-3511056.post-48580240135968665962023-11-02T09:00:00.007-07:002023-11-02T09:46:23.008-07:00Generative AI and the New Data-Driven Productivity Paradigm<p>Earlier this week, I led an <a href="https://avasant.com">Avasant</a> panel discussion on <i>Generative AI and the New Data-Driven Productivity Paradigm.</i> You can watch <a href="https://youtu.be/mE0JOxQZ2-I?si=tgiPboEUtDxvyRD_&t=176" target="_blank">the entire video here. </a></p><p>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: </p><p></p><ul style="text-align: left;"><li>Why GenAI has gotten so much attention over the past year. </li><li>Where we see GenAI delivering productivity gains as well as top line revenue growth. </li><li>Data quality as a prerequisite for realizing GenAI benefits as well as issues around confidentiality and data privacy. </li><li>The regulatory landscape around GenAI, even today with GDPR as well as in the future. </li><li>The enterprise risks for enterprises to consider in implementing GenAI systems. </li></ul><p></p><p>We ended with a lightning round about practical steps for organizations to take in getting started with GenAI. </p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://youtu.be/mE0JOxQZ2-I?si=tgiPboEUtDxvyRD_&t=176" imageanchor="1" style="margin-left: auto; margin-right: auto;" target="_blank"><img alt="What is Generative AI?" border="0" data-original-height="719" data-original-width="1285" height="224" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgr2e9Appe-Cyr_KGyi96aoWhnUJHQDR0mVkZebypm_ZjYAeLGo3YHru2BNGbC34xArqmghZJ_Uz__y5tkWL4UN3FKn_QE4RsJxXgsOz31ON580BO0CX9k7TntFkJ5kSTy0ZHph-KqhRAKHQ4eDq4iUsqx36Iv3SSZ6Ns-qwEI2C8qUt_7qgr6U/w400-h224/GenAI.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">What is Generative AI?</td></tr></tbody></table><br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3511056.post-44490473342129443482023-08-29T16:49:00.000-07:002023-08-29T16:49:16.430-07:00Opportunities and Challenges with Generative AI<p>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?</p><p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal">I blogged about this back in February, not long after ChatGPT
was released, in my post, <a href="https://fscavo.blogspot.com/2023/02/chatgpt-for-industry-research-not-ready.html">ChatGPT
for Industry Research: Not Ready for Prime Time</a>. 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? <o:p></o:p></p>
<p class="MsoNormal"><a href="https://avasant.com/report/generative-ai-opportunities-and-challenges/">Read
a summary of the interview on the Avasant website with the link to the full
video.</a> <o:p></o:p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://avasant.com/report/generative-ai-opportunities-and-challenges/" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="Frank Scavo video interview on generative AI" border="0" data-original-height="765" data-original-width="1286" height="238" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDq5uuGcVWxDDTBo21Tkpb3GTqfihPqBxnNL4s_FKGmNzH_k-rX71-w-bdAZq2E3-EaulRgkRU4UgOz-LAQSFq6jcH7RRt1yOARKRtDIqeoYTGyutn1y1Mb4ykHWkUEftfXXhS7RMfKV0qleJY_1_Hwwn8C-mR7Jxo7XH3CWzeJCBwC3prK_Pc/w400-h238/Frank-Scavo-Video-Generative-AI.png" width="400" /></a></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3511056.post-2597125304319973052023-08-21T16:51:00.007-07:002023-08-29T16:44:57.119-07:00A Teams Model for Effective Innovation <p>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.</p><p>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 <a href="https://fscavo.blogspot.com/2022/04/the-most-significant-system-development.html">developing new systems</a>, building several consulting practices, developing new research publications, or participating as a consultant on a client’s team. </p><p>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. </p><h3 style="text-align: left;">Two Conceptual Models for Working Together</h3><p>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. </p><p></p><ul style="text-align: left;"><li>The first was <a href="https://www.everythingdisc.com/" target="_blank">DiSC</a>, 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. </li><li>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. </li></ul><p></p><p>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. </p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgC0cC4vYZsI7ncKVleIGQhZE6qD_Fv-QIXtb8k04JdmBFKxh67ZZMjPXSvNwPqSrnfxqJxbaRKrQHA7CkclhTbvBDDpp4Zc1JOrh5uXV-Auh06bytBadgAaxyt9_iIIda2oSQrNZVlgfSfxb3-wYiqIdqdyZnE-rTCbnn1rkU4nwzaZLtqlJSx/s3691/CARE-model-teams.png" style="margin-left: 1em; margin-right: 1em;"><img alt="CARE model of teams" border="0" data-original-height="2480" data-original-width="3691" height="270" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgC0cC4vYZsI7ncKVleIGQhZE6qD_Fv-QIXtb8k04JdmBFKxh67ZZMjPXSvNwPqSrnfxqJxbaRKrQHA7CkclhTbvBDDpp4Zc1JOrh5uXV-Auh06bytBadgAaxyt9_iIIda2oSQrNZVlgfSfxb3-wYiqIdqdyZnE-rTCbnn1rkU4nwzaZLtqlJSx/w400-h270/CARE-model-teams.png" width="400" /></a></div><div style="text-align: center;"><i>Click to enlarge</i></div><p></p><p></p><ol style="text-align: left;"><li><b>Creators</b>. These are the idea people, who dream of new possibilities. They often start sentences with, “Wouldn’t it be great if ___________”. </li><li><b>Advancers</b>. 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. </li><li><b>Refiners</b>. 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. </li><li><b>Executors</b>. These are the team members who oversee the implementation and, if appropriate, support it on an ongoing basis. </li></ol><p></p><p>The two roles on the top—<b>Creator </b>and <b>Advancer</b>—are focused on possibilities, what could be. They have their heads in the clouds. The roles on the bottom—<b>Refiner </b>and <b>Executor</b>—are focused on realities, what is practical. They have their feet firmly planted on the ground. The two roles on the left—<b>Creator </b>and <b>Refiner</b>—are focused on analysis. They like to work with abstract ideas. The two roles on the right—<b>Advancer </b>and <b>Executor</b>—are focused on relationships. They like to work with people.</p><p>The C.A.R.E model also recognizes a fifth profile, the <b>Flexer</b>. 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. </p><h3 style="text-align: left;">Moving Through the Four Stages</h3><p>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: </p><p></p><ol style="text-align: left;"><li><b>Jumping straight from creation to execution</b>. 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. </li><li><b>Skipping the Advancer stage</b>. 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). </li><li><b>Skipping the Refiner stage. </b>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. </li><li><b>Not following through to execution.</b> 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. </li></ol><p></p><p>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. </p><h3 style="text-align: left;">My Preferred Role</h3><p>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. </p><p>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]. </p><p>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. </p><h3 style="text-align: left;">End Notes</h3><p>[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.</p><p>[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 <a href="https://avasant.com" target="_blank">Avasant</a> in 2020 and retired in 2021. </p><p>[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. </p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3511056.post-80191224851576646522023-02-14T14:47:00.119-08:002023-02-20T17:11:12.913-08:00ChatGPT for Industry Research: Not Ready for Prime Time<p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFlP0xsygzMlGVsxvZFDXZgUIvpMEoIgmUa2aG4QwfJtK1FYlN4ISF2NGXbPcEQseby9w7zfQtHIvXI8ZzJm5R755spkyv9Vbs3qPAzrkTEgWNLuKNBIdM4w8-9Ujn4Gy-5hcwGC0UJGAzLwj_kCdwMdE3iA1Z9lc06E3_Bow01RhiZ6ljVA/s454/image.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="158" data-original-width="454" height="111" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFlP0xsygzMlGVsxvZFDXZgUIvpMEoIgmUa2aG4QwfJtK1FYlN4ISF2NGXbPcEQseby9w7zfQtHIvXI8ZzJm5R755spkyv9Vbs3qPAzrkTEgWNLuKNBIdM4w8-9Ujn4Gy-5hcwGC0UJGAzLwj_kCdwMdE3iA1Z9lc06E3_Bow01RhiZ6ljVA/s320/image.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">ChatGPT: Four Errors in a Single Sentence</td></tr></tbody></table>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. <p></p><p>One inevitable question of course was, to what extent would ChatGPT threaten jobs?</p><p>For me, it’s an important question. I direct a team of IT and industry research analysts at <a href="https://avasant.com">Avasant</a>. 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? </p><h3 style="text-align: left;">Putting ChatGPT to the Test</h3><p>To find out, I did a series of tests to see if ChatGPT could write a short research note. </p><p>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 <a href="https://avasant.com">Avasant</a> in 2020. (I still manage this business as part of Avasant Research.) </p><p>Here is the transcript of my prompts and the responses from ChatGPT, lightly edited for length, along with my evaluation of ChatGPT. </p><p><b>Prompt: “Provide a history of the IT research firm Computer Economics.”</b></p><p>ChatGPT responded: </p><p></p><blockquote><i>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. </i></blockquote><p></p><p>There are four factual errors in the second sentence of this opening paragraph! Computer Economics was founded in 1979, not 1982, as documented in <a href="https://en.wikipedia.org/wiki/Computer_Economics">this Wikipedia entry</a>. (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. </p><p>But wait, there's more! A couple of paragraphs later, ChatGPT writes: </p><p></p><blockquote><i>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.” </i></blockquote><p></p><p>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. </p><p><b>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?” </b></p><p>ChatGPT responded (click to enlarge): </p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEieT_RM6G06YCGXa3OR_eQIx4Oi2OcUVuabuCZab4eUF426qUSYWuBXHmv0WOXhbNOT7Q3B7I_kbQLXWHPlwJbxOC3ylVAinKjKsU3D5Vh6ToGjKg5r5bMSwAQ18qIlrABOjuBjojES2MNaYdmCdm_WCVSsGW81g7JNkR1E9AWq2jRhwEt7GA/s1071/ChatGPT-Errors2.png" style="margin-left: auto; margin-right: auto;"><img alt="ChatGPT Hallucinations" border="0" data-original-height="695" data-original-width="1071" height="259" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEieT_RM6G06YCGXa3OR_eQIx4Oi2OcUVuabuCZab4eUF426qUSYWuBXHmv0WOXhbNOT7Q3B7I_kbQLXWHPlwJbxOC3ylVAinKjKsU3D5Vh6ToGjKg5r5bMSwAQ18qIlrABOjuBjojES2MNaYdmCdm_WCVSsGW81g7JNkR1E9AWq2jRhwEt7GA/w400-h259/ChatGPT-Errors2.png" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">ChatGPT Hallucinations</td></tr></tbody></table><p>Apparently, ChatGPT is not aware of the <a href="https://en.wikipedia.org/wiki/Law_of_holes">First Law of Holes</a>: When you find yourself in one, stop digging. </p><p>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).</p><h3 style="text-align: left;">Risks in the Use of ChatGPT for Research</h3><p>In summary, here are some observations on the risks of using ChatGPT as a virtual research analyst. </p><p></p><ol style="text-align: left;"><li><b>Fiction parading as fact. </b>As shown above, ChatGPT is prone to simply make up stuff. When it does, it declares it with confidence—what some have called <a href="https://www.entrepreneur.com/business-news/google-exec-warns-of-ai-chatbot-hallucinations/444842">hallucinations</a>. 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. </li><li><b>Lack of citations. </b>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 <a href="https://www.nist.gov/publications/four-principles-explainable-artificial-intelligence-draft">four principles of explainability</a>. </li><li><b>Risk of plagiarism.</b> 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. </li></ol><p></p><h3 style="text-align: left;">Possible Limited Uses for ChatGPT</h3><p>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. </p><p>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. </p><p>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: </p><p></p><ul style="text-align: left;"><li>What do these companies have in common? Or are the reasons for the layoffs different for some of them? </li><li>As a counterpoint, include some examples of tech companies that are hiring.</li><li>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. </li><li>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.</li></ul><p></p><p>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. </p><p>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. </p><p>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. </p><p>I will be experimenting more with ChatGPT in the near future. Hopefully, improvements in the tool will mitigate the problems and risks.<HR><b>Update Feb. 20, 2023:</b> Jon Reed has posted two lengthy comments on this post with good feedback. Check them out below in the comments section. <p></p>Unknownnoreply@blogger.com7tag:blogger.com,1999:blog-3511056.post-45589994669174751662022-10-09T10:33:00.004-07:002022-10-09T10:39:02.496-07:00What If You Held a Metaverse Party and Nobody Came? <p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglBQoS5RfVJJe_JQrdI8PMAxScAo_97Unzp8WXZZsuWS6eVJ0DN__hu7s1HSVCjwYJ5GiKRYDtXShh44Su3I11JQ-IMURt9Pd39uNxdObArA6ZavSbFKYzBFxGlSWbiFPIrgIaQHzHcp4hnlC4Z0fM6J4Gb_YgRBGXtRIH456DFAxWUSUpjw/s1056/Decentraland.webp" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="792" data-original-width="1056" height="150" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglBQoS5RfVJJe_JQrdI8PMAxScAo_97Unzp8WXZZsuWS6eVJ0DN__hu7s1HSVCjwYJ5GiKRYDtXShh44Su3I11JQ-IMURt9Pd39uNxdObArA6ZavSbFKYzBFxGlSWbiFPIrgIaQHzHcp4hnlC4Z0fM6J4Gb_YgRBGXtRIH456DFAxWUSUpjw/w200-h150/Decentraland.webp" width="200" /></a></div>The metaverse just might be the next big thing, but according to two reports this week, that time is not yet. <p></p><p>The first story is from <a href="https://www.coindesk.com/web3/2022/10/07/its-lonely-in-the-metaverse-decentralands-38-daily-active-users-in-a-13b-ecosystem/" target="_blank">CoinDesk</a>, 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. </p><blockquote><p><i>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.</i></p></blockquote><div><div class="contentstyle__StyledWrapper-g5cdrh-0 gCDWPA"><blockquote><div class="common-textstyles__StyledWrapper-sc-18pd49k-0 eSbCkN"><div class="typography__StyledTypography-owin6q-0 bYmaON at-text"><p><i>An active user, according to DappRadar, is defined as a unique wallet address' interaction with the platform’s smart contract.</i></p></div></div></blockquote><div class="common-textstyles__StyledWrapper-sc-18pd49k-0 eSbCkN"><div class="typography__StyledTypography-owin6q-0 bYmaON at-text"><p></p></div></div></div></div><p>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. </p><p>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 <a href="https://www.theverge.com/2022/10/6/23391895/meta-facebook-horizon-worlds-vr-social-network-too-buggy-leaked-memo" target="_blank">The Verge</a>, 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. </p><p></p><blockquote><i>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.”</i></blockquote><p>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 <a href="https://innovateucla.org/events/2022-executive-leadership-awards/" target="_blank">Innovate@UCLA</a>. One of the panelists, <a href="https://www.linkedin.com/in/chrismattmann/" target="_blank">Chris Mattmann</a>, 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. </p><p>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. </p><p>On the third hand, I’ve been wrong before. As I wrote earlier this year: <a href="https://fscavo.blogspot.com/2022/05/predictions-are-hard-especially-about.html">Predictions are hard, especially about the future</a>.</p><p></p><hr /><p>Image Credit: Decentraland, via CoinDesk. </p>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-3511056.post-57300598604310980492022-08-07T13:26:00.002-07:002022-08-07T13:26:33.249-07:00An Innovator’s Story: Creating a Business for Lasting Success<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZ0srf9M83vtElWOKfCEz9DkjgTsbJk1-3bP37kPRWhWR_kKXmKvygCtM4n4xZfAqH7zCNn4VFTF5wv3QIwPcLJxUzHYeUFtaTKTqBUUrQtk_wo6Wm7KPgVRF0huPbJR6BLymOkQedaRzKB8A5QR_suOoCd5KqlbFtUiZw4feENrqpS7jWkQ/s499/Jamie-Siminoff.webp" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="333" data-original-width="499" height="214" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZ0srf9M83vtElWOKfCEz9DkjgTsbJk1-3bP37kPRWhWR_kKXmKvygCtM4n4xZfAqH7zCNn4VFTF5wv3QIwPcLJxUzHYeUFtaTKTqBUUrQtk_wo6Wm7KPgVRF0huPbJR6BLymOkQedaRzKB8A5QR_suOoCd5KqlbFtUiZw4feENrqpS7jWkQ/s320/Jamie-Siminoff.webp" width="320" /></a></div>Back in May, I had the opportunity to do an on-stage interview with Jamie Siminoff, founder and CEO of Ring, as part of <a href="https://avasant.com/avasant-empowering-beyond-2022/">Avasant's Empowering Beyond Summit</a>. <p></p><p>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.</p><p>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.</p><p>Over on the Avasant website, I put together a summary of Siminoff’s keynote and my on-stage interview around two broad themes:</p><p></p><ul style="text-align: left;"><li>Lessons learned in innovation, based on Ring’s invention. </li><li>How to ensure success when an innovative startup is acquired by a much larger enterprise.</li></ul><p></p><p>The research byte concludes with Siminoff’s view on how business leaders in traditional organizations can apply the lessons in innovation.</p><p>Read the research byte on the Avasant website: <a href="https://avasant.com/report/an-innovators-story-creating-a-business-for-lasting-success/">An Innovator’s Story: Creating a Business for Lasting Success</a></p><p><br /></p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3511056.post-36099019626909653322022-05-15T16:10:00.012-07:002022-10-09T10:58:07.220-07:00Predictions Are Hard, especially about the Future<div class="separator" style="clear: both; text-align: right;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSyKCVqfxTE22lvcWvrU7WGeM-Lfwa3TwhgDU4AVzjn23Y15pPAoT0LNFFm-vUMBRqKYCxoBu_sGLLz4VoBvqUbe_VWAG8iv5xFsLJFLTG3Yxgyl1_3sfrCgxtxqV3UYUL0gZYLa4ksuqBUZa5rBjfy4W4ntduHSpTx0q8zqaXsCxmoak28Q/s400/Gemco-Membership-Card.jpg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="Gemco Membership Card" border="0" data-original-height="247" data-original-width="400" height="124" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSyKCVqfxTE22lvcWvrU7WGeM-Lfwa3TwhgDU4AVzjn23Y15pPAoT0LNFFm-vUMBRqKYCxoBu_sGLLz4VoBvqUbe_VWAG8iv5xFsLJFLTG3Yxgyl1_3sfrCgxtxqV3UYUL0gZYLa4ksuqBUZa5rBjfy4W4ntduHSpTx0q8zqaXsCxmoak28Q/w200-h124/Gemco-Membership-Card.jpg" width="200" /></a></div>With nearly half a century in enterprise IT, I have had plenty of time to see how technology predictions over the years have been fulfilled—or not fulfilled. This was brought home to me recently while reviewing an old project document.<br /><br />But first, some context. As noted in <a href="https://fscavo.blogspot.com/2022/04/the-most-significant-system-development.html">my previous post</a>, I felt forced by a business downturn in 1983 to resign from Smith Tool and take an IT manager position at Gemco, a now defunct membership department store, then owned by Lucky Stores. This returned me to my retail roots.<br /><h3 style="text-align: left;">A Prescient Prediction</h3><div>Although I only stayed at Gemco a few months, I was put in charge of a strategic systems project: To define the requirements for a new merchandising system. We started by interviewing the senior leaders of the firm and worked our way up the organization until we reached the final interview with the CEO, Peter Harris [1]. <br /><br />The interview summary, dated October 18, 1983, is quite interesting, especially in one paragraph where Harris said:<blockquote><div><i>We need to recognize the changes that will come in the next decade due to the spread of advanced telecommunications. It is likely that 50% to 70% of basic hardgoods and commodities will be purchased from home, eliminating the need for store visits. However, apparel and other fashion merchandise will continue to be purchased in store environments, because of the psychological need to “go shopping.”</i></div></blockquote><div>Today, I do not recall anyone in the retail industry in the early 1980s predicting the dawn of B2C e-commerce. And apparently, even 10 years later, I was still a skeptic. In the margin of that final report, there appears a note, in my own handwriting.</div><div><blockquote><i>How wrong he turned out to be! –FS, 3/15/93 (10 years later!)</i></blockquote><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3yj6UWPbSfijl0z8phZfH22Xtkp6AiFqWpFoEPyYdwm--WxiWWHSQLnD-QwwhLQR-d1J2pDYAzTza2bBOnXvdLWT0icQd4Q0QGagNghjLqNFhp5kiI1aPHIEmu0sZ29fD23VuCYknO8Ai2rVMuR2eV6AbQGc6RqMkXLglkKi_Uo4Kl_2KOg/s816/HarrisQuote2.png" style="margin-left: 1em; margin-right: 1em;"><img alt="Peter Harris Interview Quote" border="0" data-original-height="214" data-original-width="816" height="105" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3yj6UWPbSfijl0z8phZfH22Xtkp6AiFqWpFoEPyYdwm--WxiWWHSQLnD-QwwhLQR-d1J2pDYAzTza2bBOnXvdLWT0icQd4Q0QGagNghjLqNFhp5kiI1aPHIEmu0sZ29fD23VuCYknO8Ai2rVMuR2eV6AbQGc6RqMkXLglkKi_Uo4Kl_2KOg/w400-h105/HarrisQuote2.png" width="400" /></a></div><p>But little did I know, 1993 was the year that the U.S Congress passed a law to <a href="https://internethistory.org/commercialization/">commercialize the Internet</a>, and it was also the year that Tim Berners-Lee invented the World Wide Web. And, one year later, Jeff Bezos founded Amazon. But it took another two decades before a worldwide pandemic pushed B2C e-commerce for certain categories of goods to the levels that Peter Harris predicted nearly 40 years earlier.</p></div><div>So, no, Harris’s prediction was not wrong. He was just off by about 30 years.</div><div><h3 style="text-align: left;">Lesson Learned: Keep an Open Mind</h3></div><div>As Yogi Berra once said, predictions are hard, especially about the future. Like many others, I tend to be a skeptic, always looking for the negative side of an idea, or what could go wrong. In fact, a few years ago, I wrote a <a href="https://fscavo.blogspot.com/2014/12/eight-incredibly-useful-tips-for.html">blog post mocking fellow analysts</a> who make year-end predictions. I don't like to make predictions myself and I tend to be skeptical of those who do make them. I have to make a conscious effort to fight this tendency. <br /><br />So what predictions are out there that might seem far-fetched today but could eventually come into realization?<br /><ul style="text-align: left;"><li><b>The Metaverse. </b>There are many breathless predictions these days about “the metaverse,” a virtual world where people and organizations can live and interact in a persistent and immersive 3D environment, where they can own virtual property, trade virtual goods, and be educated or entertained. Some argue that the metaverse already exists with various gaming platforms. Others think it is being overhyped by social media companies, such as Facebook (now branded as Meta) that are otherwise out of ideas about how to keep people engaged on their platforms in order to target them for advertisements.</li><li><b>Non-Fungible Tokens.</b> NFTs have been a hot market over the past year, with sales of digital art, secured by NFTs on a blockchain, trading for thousands or millions of dollars. The fact that any piece of digital art can be saved with a mouse right-click makes it difficult to understand what exactly an NFT denotes in terms of ownership. The recent and rapid decline in the value of various NFTs confirms to skeptics that they are nothing more than the 21st century equivalent of <a href="https://www.investopedia.com/terms/t/tulipmania.asp">Tulipmania</a>. </li><li><b>Cryptocurrencies.</b> Digital currencies using cryptography, such as Bitcoin, are built using blockchain technology. In contrast to fiat money, such as the US Dollar, they are not backed by a central government but are decentralized, permissionless, and virtually impossible to corrupt. Advocates predict they will replace fiat money, or at least exist alongside it, providing a hedge against inflation and very low transaction costs compared to traditional currency exchanges. At this writing, there is a collapse in cryptocurrency markets, confirming the view of crypto-critics that the whole thing is one big bubble.</li></ul>It is easy to be a critic, or as <a href="https://www.debono.com/six-thinking-hats-summary">Ed Debono taught</a>, to put on the black hat. It is not so easy to see the problems with an idea while at the same time seeing where there could be value. It is even more difficult to predict when exactly that value might be realized. <br /><br />Sometimes, predictions are not wrong. They just take longer than we think to be realized.</div><div><h3>Footnote</h3></div><div>[1] Peter Harris is an interesting person, starting as a stocking clerk at Gemco and eventually working his way up to President from 1980 to 1984, when the firm achieved $2.2 billion in revenues. Later, he and his partner acquired FAO Shwarz, where he took over as CEO until 1992. Later, he became the President and CEO of the San Francisco 49ers (2000-2004), and held several other leadership positions after that. Today, he is retired and serves on several boards, including Palo Alto Medical Foundation. <a href="https://www.linkedin.com/in/peter-harris-063804a/">He is still on LinkedIn</a>.</div><div><h3>Update, May 22, 2022 </h3></div><div>One of the joys in writing this series of career posts is reconnecting with people I worked with decades ago. So, I sent a message to Peter Harris on LinkedIn.</div><div style="text-align: left;"><blockquote><i>Peter, I'm sure you don't remember me, but I interviewed you in 1983 at
Gemco. I just wrote a blog post about your prediction about E-commerce. [Link to this post.] Let me know any feedback. --Frank</i></blockquote></div><div>This morning he wrote back:</div><div><blockquote><p class="MsoNormal"><i>Frank, I am absolutely blown away to hear from you and read of your perspective, highlighted of course by your absolutely amazing record keeping mention of something I said many years ago. While I think 30 years early doesn't count as anything beyond being impracticably thoughtful, I was honored and hugely appreciative to be recognized. Your article is fascinating and I am now following you so that I might observe and learn from your thinking and musings on other topics. That you have tracked me down on LinkedIn and shared it means a lot. The appropriate comments are "way cool," "awesome" or maybe even "wowza." Thank you so very much. I'd be interested to hear a bit more than is visible on LinkedIn about what you are doing now if you have time to share. --Peter</i></p></blockquote></div><div>[Posted with Peter's permission.]<br /><h3 style="text-align: left;"><b>Update, Aug. 8, 2022</b></h3></div><div>The same year, 1983, Mark Dertouzos made this incredible prediction of the World Wide Web. Click to watch. <div class="separator" style="clear: both; text-align: center;"><a href="https://twitter.com/MIT_CSAIL/status/1556689555251638272" style="margin-left: 1em; margin-right: 1em;" target="_blank"><img alt="Mark Dertouzos video thumbnail" border="0" data-original-height="238" data-original-width="295" height="161" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg0RoC4yAcC1iVEpnu3BZT_yMM29qpfE2osAB2HG7jCmSVZTkmqh-ZyeJOVXmRlTaEJW2Z1NuAxmzgHYy2yucBMsmK6sZcbIw9_lAHSpk4OVqi5h7K9mPdlmd3C2s4HIyStWoXie_wqOD7dt8_sbyTbbTF0KmXsuVN-t_-gCRztDz25D2T12w/w200-h161/MarkDertouzos.png" width="200" /></a></div></div><div><br /></div><div><b>Photo Credits:</b><br /><ul style="text-align: left;"><li><a href="https://www.worthpoint.com/worthopedia/vtg-ca-1970s-gemco-life-membership-508144666">Gemco Membership Card</a></li><li>Peter Harris Interview Notes: Frank Scavo<br /></li></ul><o:p></o:p><p></p>
<p class="MsoListParagraphCxSpLast" style="mso-list: l1 level1 lfo2; text-indent: -0.25in;"><o:p></o:p></p></div></div>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-3511056.post-5817717676320808122022-04-20T15:09:00.014-07:002022-09-02T14:43:15.199-07:00The Most Significant System Development Project of My Career<p></p><div class="separator" style="clear: both; text-align: right;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCD6NTh26f7z_Yx4Yr8otWSGuoLpVHcxbOSx9R9HaN5LKMBUtINrJwTt2ljpnNarMfJWwlauu5YQlCHcwrOoF_UnGoXDtEu1FWoDxwgy0AP1M_XuXA_ZsKRxtkwoPHGxx2YUPWEqv6TygKBk4keQXsVGiismG2yoyBDq_ALD6Sa9oWXKpVng/s1280/DrillRigPixabay.jpg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="Drill rig" border="0" data-original-height="1280" data-original-width="960" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCD6NTh26f7z_Yx4Yr8otWSGuoLpVHcxbOSx9R9HaN5LKMBUtINrJwTt2ljpnNarMfJWwlauu5YQlCHcwrOoF_UnGoXDtEu1FWoDxwgy0AP1M_XuXA_ZsKRxtkwoPHGxx2YUPWEqv6TygKBk4keQXsVGiismG2yoyBDq_ALD6Sa9oWXKpVng/w150-h200/DrillRigPixabay.jpg" width="150" /></a></div>This post continues my series on lessons learned in my nearly half century in enterprise IT. We started in 1974 with <a href="https://fscavo.blogspot.com/2019/06/what-i-learned-at-macys-about.html">my job at Macy’s</a> headquarters in Manhattan, followed by my move to California in 1976 and my job at <a href="https://fscavo.blogspot.com/2021/06/enterprise-it-at-trw-credit-data.html">TRW Credit Data</a>. I then took a job at <a href="Smith Tool">Smith Tool</a> in 1978, where I got thrown into the deep end with manufacturing systems. This led to several more important lessons learned, including the <a href="https://fscavo.blogspot.com/2021/09/what-i-learned-from-waterfall-project.html">failure of a waterfall development project</a> and my <a href="https://fscavo.blogspot.com/2021/10/my-first-encounter-with-shadow-it.html">first encounter with shadow IT</a>.<p></p><p>But there were more lessons to be learned at Smith Tool. </p><p>Next would be the biggest and most important project of my career. Rolling off a series of manufacturing system development projects, I was now assigned to a task force to develop a strategic system to analyze the performance of Smith’s drill bits in the field. I would be the project manager for a small team of developers and the overall system architect. </p><h3 style="text-align: left;">An Unspoken Objective</h3><p>The first phase was to build a bit record database, which would become the foundation for several future systems. The database, which would ultimately contain millions of historical drilling records from around the world, would be used for preparing well proposals, evaluating product performance, conducting competitive analysis, and providing a feedback loop from the field to engineering to improve product quality. </p><p>But there was another, unstated objective. Smith Tool had been sued for patent infringement by Hughes Tool (the business that made Howard Hughes his initial fortune). The patent was for a novel application of an O-ring, which sealed the lubricated bearing of the three roller cones from the harsh downhole conditions. O-rings (made famous for their failure in the space shuttle Challenger disaster) were in common use at the time, but Hughes had discovered that if you squeezed the O-ring a bit it actually extended the life of the seal. This was counter-intuitive, but it worked. The litigation had been dragging on for over a decade, starting with Smith getting a federal court in 1979 to invalidate the patent, and Hughes getting a federal appeals court in 1982 to reverse that decision. That was just before I was assigned to the development project, which would be an important element in Smith’s defense. </p><p>The lawsuit, for about $1 billion, was at that time the largest patent infringement case in history. The lawsuit alleged that Smith’s use of the Hughes patent made Smith’s bits competitive with Hughes, earning Smith profits that it would otherwise not have earned. To defend against the Hughes claim, Smith would need a system to provide the data analysis. </p><p>None of this was mentioned to me at the time. I only knew that the project was getting me a lot of attention from top management. In fact, my old manager, Rodger Beard, recently told me that at corporate headquarters they were talking about how my system would “save their bacon.” </p><h3 style="text-align: left;">Lesson Learned: Immerse Yourself in the Business</h3><p>Shortly after the project kick-off, I learned that there was a week-long training program about to start for new field sales people. I invited myself in and got to sit through detailed lessons on Smith’s products and how they were used by customers. I found the whole week fascinating. [1]</p><p>Halfway through the week, Dan Burtt, the IT director, noticed I was not at my desk and found out about the class. “Why is Frank taking sales training?” he asked. I managed to convince him to let me finish. </p><p>Since I had been developing or maintaining many of Smith’s manufacturing systems, I already understood the engineering and production data that would be needed to correlate with field performance. What I lacked was an understanding of that field data. My degree in Geology helped, but all of this was mostly new information. </p><p>There were also some thorny design problems, such as how to designate well locations in different parts of the world, using different coding schemes. I spent several hours at the UC Irvine library learning about various geographic location systems in use in the U.S. and around the world, such as the section-township-range system, <a href="https://en.wikipedia.org/wiki/Public_Land_Survey_System">originally proposed by Thomas Jefferson</a>. </p><p>In any new system development project, you have to start with a deep understanding of the business. It is not enough to have users tell you what they need. It’s more than gathering requirements. You have to have a sense of curiosity and immerse yourself in the industry and the business.</p><h3 style="text-align: left;">Lesson Learned: Take Advantage of Career Adversity</h3><p>But the oil industry is notorious for booms and busts, and we were heading into a major bust. There was a massive company layoff, and the IT staff was not excluded. With fewer IT personnel, we didn’t need as many first level managers, so I was demoted back to project manager. Even worse, after I finished the requirements definition, my project was put on hold pending budget approval to move forward. This was the last straw. I resigned in August 1983 and returned to my retail industry roots, taking an IT manager position at Gemco, a now-defunct membership department store.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFHoq_yFcHVZpz8sChf2uJqJ9t__gUKY6N_b4rDZopqmrxW7Aln_eCj2LQ1elyGyzIfL8E17VDA9b2D0S3Z15tVWjGtI8A8Go2E4N_idJCdwfRHjV5GeBp7l_38W79sWkc9Ym1_vFNcEqN72smQrBcfRHc_tzfKqsdMp24UmyweQBBhGbqKg/s401/Beta-Management-Systems-Logo.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="Beta Management Systems Logo" border="0" data-original-height="161" data-original-width="401" height="80" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgFHoq_yFcHVZpz8sChf2uJqJ9t__gUKY6N_b4rDZopqmrxW7Aln_eCj2LQ1elyGyzIfL8E17VDA9b2D0S3Z15tVWjGtI8A8Go2E4N_idJCdwfRHjV5GeBp7l_38W79sWkc9Ym1_vFNcEqN72smQrBcfRHc_tzfKqsdMp24UmyweQBBhGbqKg/w200-h80/Beta-Management-Systems-Logo.png" width="200" /></a></div><p></p><p>But, after a few months I got a call from Smith. The bit record project had been funded. Could I come back to lead it? I said yes, on one condition: I wanted to come back as a consultant, not an employee. I had been thinking for some time about a consulting career, and this was my opportunity. Smith agreed—I had so much knowledge of the project and the business requirements that it seemed like a small request. </p><p>This launched my consulting career, as a sole proprietor doing business as Beta Management Systems. [2] [3]</p><h3 style="text-align: left;">Development, Implementation, and a Move into the Business</h3><p>Now I was back at Smith, leading a small team of developers. I designed the system mostly as an online system (IBM’s CICS) but with a little batch programming to extract manufacturing and engineering data on a nightly basis. As usual, I wrote some of the most important code myself. The database was eventually going to hold millions of records, and it would be used for online analytical processing (OLAP), so it needed to be fast. I designed the database in IBM’s VSAM, and I set up alternate indices to provide quick access for the most common types of standard reporting. This was before the days of widespread use of relational databases, or at least before Smith had one. </p><p>For the OLAP reporting, I used something new. The year before I had gotten trained in FOCUS, a fourth-generation language from Information Builders (acquired by TIBCO in 2021). This was an excellent tool for reporting and analysis, especially for ad-hoc inquires. This is how I would develop the OLAP reporting that would prove instrumental later on in supporting the patent litigation. </p><p>Initial system development took less than a year. I still have a copy of the system user guide, dated November, 1984. Users began loading bit records in 1985. </p><p>As soon as the system went into production, there was no more need for me in the IT department. But there was a huge need in the engineering department, where all that ad-hoc analysis would need to be done against the database. So, I left IT and went down the street to the “Hobie Cat Building” (the former owner) to begin as a consultant in the engineering group known as Product Evaluation. [4] </p><p>Within Product Evaluation, I became part of a small team to develop the OLAP reporting for the bit record system. Looking back, this was the best experience I’ve ever had in a team. There was our manager, Jim Watson, who was a metallurgist by training and product failure analyst. Jim became a personal friend of mine over the years. There was Steve Steinke, a geologist, who provided the knowledge of the oil field. Rounding out the team was Joel Palmer, a statistician, who ensured that our analysis was statistically valid. Then there was me, the systems guy. </p><h3 style="text-align: left;">Lesson Learned: Understand Basic Statistics</h3><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggDuHdDvfmKaaGVsi9RNYf4vgneyejtwmGfIjoJdeX_KirBlKt_ARwBTtFVOuraM55qoohe-05cM7r3H9KxGLO6fdZE0RRe5I0fIv2S1Msq8kRY74fZTrFIP-XyUgRu3fI2WNcbEf3Xp6K8gCjy1044Dz_Yt9ZFwfeRsHg7aItz_aegkkDvA/s536/Calc-Basic-Statistics.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="Textbook cover--Calculate Basic Statistics" border="0" data-original-height="536" data-original-width="365" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggDuHdDvfmKaaGVsi9RNYf4vgneyejtwmGfIjoJdeX_KirBlKt_ARwBTtFVOuraM55qoohe-05cM7r3H9KxGLO6fdZE0RRe5I0fIv2S1Msq8kRY74fZTrFIP-XyUgRu3fI2WNcbEf3Xp6K8gCjy1044Dz_Yt9ZFwfeRsHg7aItz_aegkkDvA/w218-h320/Calc-Basic-Statistics.png" width="218" /></a></div>Looking back, I now appreciate how the statistical validity of our analysis would be critical. This was important not only because we needed to ensure that the conclusions of our analysis were on a sound footing generally, but also because some of our analysis would be presented in court in Smith’s legal defense. <p></p><p>I had started out as a math major at UPenn, but I’d never had a course in statistics. So, even though we had a statistician on our team, Smith brought in Dr. Mark Finkelstein, a mathematics professor from UC Irvine, to coach us once a week on basic statistics. He used <a href="https://www.amazon.com/Calculate-Basic-Statistics-Mark-Finkelstein/dp/0936356014">his own text book</a>, pictured nearby. We learned about descriptive statistics and inferential statistics, regression, correlation, and confidence intervals. </p><p>The key point I learned was this: Just because a data set appears to show a correlation between two variables, it might not be statistically significant. For example, I might be asked to divide a sample of bit runs from a group of nearby wells into three groups according to some engineering parameter. My analysis might show that as the parameter increases, the bit performance improves. But that conclusion might be spurious. On more than one occasion I had to tell the requestor that, even though a graph might appear to support his theory, the statistics did not. </p><p>Eventually, the Smith lawyers asked me to perform statistical analysis in support of the patent litigation. In response to the court ruling that Smith was infringing on the Hughes patent, Smith had redesigned its bits to use an older seal, called a Belleville seal, instead of the O-ring. Smith contended in court that the new seal provided performance equal to that of the O-ring, and my analysis supported that conclusion. But the new seal was more expensive than an O-ring, increasing the cost of a tricone bit by about $29. According to a <a href="https://www.latimes.com/archives/la-xpm-1986-03-17-fi-22432-story.html">Los Angeles Times account</a> of the trial: </p><blockquote><p>According to [Judge] Hupp’s chronology of the events that led to Smith’s using Hughes’ patented device, Smith stopped manufacturing the Belleville-type seals in 1972, in part because they made the Smith device cost about $29.02, or an estimated 3.2% of the total purchase price, more than the competing Hughes product.</p></blockquote><p>Smith’s attorneys argued, therefore, that the damages to be awarded Hughes should be calculated based on the difference in product cost for the half million infringing bits, or about $14.5 million, rather than the billion-plus that Hughes was claiming. </p><p>Bottom line, as I was told: The judge agreed that the performance of the Belleville seal was equal to that of the O-ring but did not agree that damages should be based on the difference in cost. The judge assigned damages of just over $200 million. In other words, we won the battle that I was fighting, but lost the larger war. [5]</p><p>My appreciation of statistics would benefit me later in my career, when Dan Husiak and I acquired the IT research firm Computer Economics. I took over the research group, which collected and published metrics on IT spending and staffing. Many times, I was confronted with what appeared to be a correlation between IT spending and some other metric. My experience from Smith Tool taught me to be skeptical if the sample size was small. </p><h3 style="text-align: left;">Postscript: Successor System Still Delivering Value</h3><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXp8qHbbYiNCzrVlOOerfYi6fTgb-qFh9r3KuclmZk_01yszbiI_lsvDlu4STLIB8lscLwNJwwl71Rj40kuD5anAwxDkqoAI4ZL3zQ-v2oyiZWcc8pIPY5vc8aF6UShrm5T7HhPYZDh_Y8DEZ4kYCjnh33bYyt82xRH7P0AVhdcvMFK3ROsQ/s768/DRS1.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="DRS Drilling Record System log in panel" border="0" data-original-height="768" data-original-width="732" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXp8qHbbYiNCzrVlOOerfYi6fTgb-qFh9r3KuclmZk_01yszbiI_lsvDlu4STLIB8lscLwNJwwl71Rj40kuD5anAwxDkqoAI4ZL3zQ-v2oyiZWcc8pIPY5vc8aF6UShrm5T7HhPYZDh_Y8DEZ4kYCjnh33bYyt82xRH7P0AVhdcvMFK3ROsQ/w191-h200/DRS1.png" width="191" /></a></div>The combination of the court judgment, a continuing downturn in the oil industry, and some poor business decisions was too much for Smith to overcome. The company filed for Chapter 11 bankruptcy protection, divested noncore businesses, and was able to come out of bankruptcy in the same year. I was still working as a contractor to Smith through this entire time, but at less than a full-time basis. This gave me time to develop business with other clients. <p></p><p>So, what happened to the Bit Record Database? In 1988, while I winding down my work on the system, Steve and Jim delivered a <a href="https://doi.org/10.2118/17189-MS">presentation</a> at the IADC/SPE Drilling Conference. They reported that the system contained 100,000 bit records. They also reported that the team had built an interface from the mainframe to PCs running dBase in field offices. This was how they were preparing bit programs for new wells. </p><p>Then, in the mid-1990s, I got in touch again with Steve, who told me that Smith had migrated the system from the IBM mainframe to a personal computer running the Progress database. </p><p>So, in writing this post, I got curious: Where is the Bit Record System today? Smith was acquired by Schlumberger in 2010, who rebranded the Smith Tool business as <a href="https://www.slb.com/companies/smith-bits">Smith Bits</a>. A little digging uncovered a recent edition of the Smith Bits product catalog, and it has an interesting page on something called the “DRS drilling record system.” </p><blockquote><p>The Smith Bits DRS drilling record system is a collection of nearly 3 million bit runs from virtually every oil and gas field in the world. <u>The database was initiated in May 1985</u>, and since that time, records have been continuously added for oil, gas, and geothermal wells. With this detailed data and the capabilities of the IDEAS platform, Smith Bits engineers can simulate bit performance and make changes to their bit designs to optimize performance in a specific application. [Emphasis added]</p></blockquote><p>With that date of May 1985, I have no doubt that this is the successor to the Bit Record Database. It is interesting that Schlumberger has renamed the system as the Drilling Record System. It may be because even in my original design the system included data on bottom hole assembly tools other than rock bits and other drilling data such as hydraulics. We called it the Bit Record Database because the form that the system was based on was commonly called a bit record. A DRS screen shot is shown below (click to enlarge). </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg46-DCBd3TqHQhe9x0aL_ZL_K4sbyvbmqYZCb0onCl9VmOEznPEABlLY-1PNED1gcIs9TuzFCV-UHNIEmGiDGBNrrCUsRJNcOUjEjkw_cIVwujlyF2Jv5qUckMempDH-KKxy5rr_HPCAgioi9PdppCWIt9CakERMKXBEf_np9ZtkA2ndCWAQ/s1140/DRS3.png" style="margin-left: 1em; margin-right: 1em;"><img alt="DRS Drilling Record System screen shot" border="0" data-original-height="868" data-original-width="1140" height="305" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg46-DCBd3TqHQhe9x0aL_ZL_K4sbyvbmqYZCb0onCl9VmOEznPEABlLY-1PNED1gcIs9TuzFCV-UHNIEmGiDGBNrrCUsRJNcOUjEjkw_cIVwujlyF2Jv5qUckMempDH-KKxy5rr_HPCAgioi9PdppCWIt9CakERMKXBEf_np9ZtkA2ndCWAQ/w400-h305/DRS3.png" title="Click to enlarge" width="400" /></a></div><p><b>Update, Aug. 13, 2022</b>. I have now reconnected with my old teammate, Steve Steinke, who retired two years ago from Schlumberger's Smith Bits group. Steve worked with the DRS system over all those years since we were together. Steve confirmed my recollection of our discussion in the early 1990s that Smith converted the system to a single PC running the Progress database. The main motivation for this was to get off the mainframe. Then around 1999, Smith rewrote the system on an Oracle platform. At the same time, they greatly expanded its functionality to include records of other downhole tools besides rock bits. The team continued to expand the system to include records of other drilling equipment and systems as well. It now even includes geological data, such as formations encountered at various depths. Today it contains something like 1.5 million wells and is used by other Schlumberger business units in addition to Smith Bits. </p><p>In an interesting side note, Steve confirms that the worldwide geographic location coding system I developed is still part of the system design. But Steve personally enhanced the design to automatically derive latitude-longitude from section-township-range, to more easily identify offset wells. </p><p>In any event, I am proud that the system development work I did in the 1980s, over a period of about eight years, still continues to deliver value today. </p><hr /><h3 style="text-align: left;">Footnotes</h3><p>[1] The training sessions were not all technical. There were lessons on how to behave properly in the field, including advice such as, when driving through a gate on a cattle ranch, be sure to close the gate behind you. Another lesson told us not to beg for business or claim that you’ll get fired if you don’t make the sale—unless that’s the only way to close the deal. There was another lesson with a pamphlet entitled, “How to Turn WAGs into SWAGs,” where a SWAG is a scientific WAG. It had something to do with using data in sales proposals. We also learned that in the early days, Smith was known as the “Whisky Bit,” because sales people would put a bottle of whisky in the pin of the bit. So, when the roughnecks would get thirsty, they’d say, “Let’s open one of them whisky bits.” </p><p>[2] There was no significance to the word Beta. I didn’t have money to spend on a logo, so I figured I could get the printer to use the Greek letter beta in place of the normal font. That allowed me to use the business name as a logo. </p><p>[3] Having at least a year of guaranteed contract work, maybe more, was a huge factor allowing me to break into consulting. A year earlier, our third child, Joanna, was born, and we had just bought our first home. Finances were tight. As it turned out, though, my work with Smith took me through most of the 1980s as I then began to add other clients, mostly through referrals from other “Smithereens” (people who had quit or left Smith during the rounds of layoffs). </p><p>[4] Among other responsibilities, the Product Evaluation group provided post-mortem analysis of bits that failed in the field. They had a large room that they called the “morgue,” with bits that had failed, laid out in table top trays. The group included metallurgists and engineers that did root cause analysis to determine the causes of failures and make recommendations for changes in product design, manufacturing processes, and quality procedures. </p><p>[5] This was a stressful time, with the Smith legal team often asking for additional ad-hoc analysis, sometimes just as I was about to leave for the day. But, to their credit, they did a good job keeping my name out of discovery so I wouldn’t have to be deposed. I think it helped that I was a contractor and not a Smith Tool employee. Not that we had anything to hide. But it wouldn’t have been a pleasant experience. Jim and Steve were deposed and testified in court. I got to see a trial transcript, and from what I read and what they told me, it was grueling. </p><p>Photo Credit: <a href="https://pixabay.com/photos/onshore-drilling-rig-derrick-1928356/">Drill Rig, Pixabay</a></p><div><br /></div>Unknownnoreply@blogger.com017871 Von Karman Ave, Irvine, CA 92614, USA33.6884025 -117.84764285.3781686638211568 -153.00389280000002 61.998636336178848 -82.6913928tag:blogger.com,1999:blog-3511056.post-15975931400000118862021-12-24T12:59:00.001-08:002021-12-24T12:59:44.336-08:00Cerner Acquisition to Launch Oracle Higher into Healthcare<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/a/AVvXsEhoMZK_0VpifzMtX_c7E5ulZpKS0ip_eHeV77F0Mq9TYB4PMSabUA1NBkE7panr8mZ4akkjW86UfpIgu7wPHm6fSdAzvU7U8DO6FQWx6jJXBd1sSnKEnYk7AHsjrJIBbOGGM_nJ3m1BxJeC4xyIpkLHhKVEGFPfj7J_jnlh7n9ujT-uz47ueA=s449" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="Oracle Logo and Cerner Logo with medical doctor using a touch screen" border="0" data-original-height="300" data-original-width="449" height="214" src="https://blogger.googleusercontent.com/img/a/AVvXsEhoMZK_0VpifzMtX_c7E5ulZpKS0ip_eHeV77F0Mq9TYB4PMSabUA1NBkE7panr8mZ4akkjW86UfpIgu7wPHm6fSdAzvU7U8DO6FQWx6jJXBd1sSnKEnYk7AHsjrJIBbOGGM_nJ3m1BxJeC4xyIpkLHhKVEGFPfj7J_jnlh7n9ujT-uz47ueA=w320-h214" width="320" /></a></div>Earlier this month, Oracle and Cerner jointly announced an agreement
for Oracle to acquire Cerner, a provider of digital systems to
healthcare providers. The deal of approximately $28 billion will be the
largest in Oracle’s history, nearly three times the size of its
PeopleSoft acquisition in 2005.<p></p><span class="tsText">
<p>
To understand the rationale behind the deal and what it means for the
two companies, the industry, and especially for Cerner customers, we
interviewed Avasant partners, consultants, and fellows who focus on the
healthcare industry. This research byte summarizes our point of view.</p><p>Read this post on the Avasant website: <a href="https://avasant.com/report/cerner-acquisition-to-launch-oracle-higher-into-healthcare/">Cerner Acquisition to Launch Oracle Higher into Healthcare</a></p></span>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3511056.post-7247166656863449722021-10-24T11:28:00.006-07:002021-10-24T14:43:28.007-07:00My First Encounter with Shadow IT<div class="separator"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVI_hoFiV5fuMm82db6GVil0-mlwjS9Ygp_VInXRcc1xTCkZfZu9uHhNUDa3z_QiOk1XO_p8lMQ5tybuw0_6a9WK1km81J9V3srsdDsPWnmOVz8n29rytbWsLTXZ597KGjbkdw/s303/303px-TRS-80_Model_4_%2528modified%2529.jpg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="TRS-80 Home Computer" border="0" data-original-height="240" data-original-width="303" height="199" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVI_hoFiV5fuMm82db6GVil0-mlwjS9Ygp_VInXRcc1xTCkZfZu9uHhNUDa3z_QiOk1XO_p8lMQ5tybuw0_6a9WK1km81J9V3srsdDsPWnmOVz8n29rytbWsLTXZ597KGjbkdw/w252-h199/303px-TRS-80_Model_4_%2528modified%2529.jpg" width="252" /></a></div>In my recent post on <a href="https://fscavo.blogspot.com/2021/08/what-i-learned-at-smith-tool-about.html">what I learned about enterprise IT at Smith Tool</a>, I mentioned that I needed another few posts to cover some of the more interesting lessons learned. I already covered what I learned from <a href="https://fscavo.blogspot.com/2021/09/what-i-learned-from-waterfall-project.html">a failed waterfall development project</a> in 1980. But the lessons kept coming, shortly thereafter, in my first encounter with “shadow IT.” <div><br /></div><div>Shadow IT commonly refers to information systems that are purchased or developed apart from the corporate IT department. <h3 style="text-align: left;">An Inventory System for Tooling</h3><p>In 1981, I got a new assignment: to develop a system to manage inventory of perishable tooling in the manufacturing plant [1]. Our manufacturing systems, some of which I had developed, did a fairly good job of managing inventory of direct material—raw materials and parts that went directly into the finished product. But they did not yet fully manage the inventories of tooling that were needed to make those parts, such as cutting tools and grinding wheels. Managing tool inventory was important, because a stock-out of tooling could delay a production order just as much as a stock-out of direct material could. </p><p></p><p>We had already built systems to maintain tooling bills of material (tool lists) and to associate those tool lists to production orders. We had also built a system to track tool usage on production orders. But we had not yet closed the loop to track on-hand inventory of tooling and to plan for replenishment based on production plans. The existing manual system was nothing more than an intricate paper-based min/max system that required a physical inventory count three times a day! Expediting to cover shortages of tooling was a way of life. As a result, my analysis showed that 90% of manufacturing production order delays were the result of tooling being unavailable. The benefits of an automated system would be huge [2]. </p><p>Some perishable tooling items were purchased. The rest were fabricated in Smith’s own tool-making shop or subcontracted to outside tool makers. The tool room was, in essence, a factory within a factory, and it would ultimately require a manufacturing planning and control system linked to the main MRP system at Smith Tool. This is a key point in the lesson learned to come. </p><h3 style="text-align: left;">A Startling Discovery</h3><p></p>My first step was to take a walk out to the tool crib to meet with the Manager of Tool Control (“Fred”), gather some data, and talk to him about his requirements. The conversation, as I recall it, went something like this. <p></p><p></p><blockquote><p>Me: “Hi Fred, as you may have heard, we’re starting to gather requirements for a new Tooling Inventory System to replace your manual system.” </p><p>Fred: “Oh, no need to do that, we’re going to install the computer system that they’re using over in the San Bernardino plant.” </p><p>Me: “Wait, what?” </p><p>Fred: “Yeah, the guys over in San Bernardino didn’t want to duplicate our manual system, so one of the NC programmers put together a system on one of those TRS-80 computers you can get at RadioShack[3]. It only took him a few weeks to program it.”</p></blockquote><blockquote><p>Me: “Fred, wait a minute. I’m not out here setting up my own tool room. So, you guys shouldn’t be setting up your own computer system. That's my department.” </p></blockquote><p></p><blockquote><blockquote><p></p></blockquote><p></p></blockquote><p></p><p>After this, I managed to calm down and got a walk through to see the tool crib operations and to gather some sample documents. </p><p>When I returned to the IT department, I went straight to Rodger’s office to tell him what happened. He told me that I’d better take the 90-minute drive out to San Bernardino to see this rogue TRS-80 system. </p><h3 style="text-align: left;">Evaluating the Shadow IT System</h3><p>The IBM PC would be on the market in just a few months (August, 1981), opening the floodgates to what would later be called end-user computing. But this was my first encounter. What stunned me the most was not just that my users had usurped my job of systems development but that they appeared to have done in a few weeks what we had planned to do in a six month effort. However, as I would soon learn, the scope of what they had done on the TRS-80 fell far short of what we were planning to do on the mainframe. </p><p>The first thing I saw involved limitations of the TRS-80 hardware as a business computing platform [4]. These were easy observations. But, as we all know, personal computers would soon overcome those limitations and become a real disruption to mainframe computers.</p><p>My more strategic observation, however, was that the TRS-80 system only addressed a single need in what should be a closed-loop end-to-end process for managing tooling. There were no tooling bills-of-material (tool lists), no tracking of tool usage, no association of tool lists to production orders (at multiple revision levels), and no determination of tooling demand based on planned or released production orders—all functionality that we had already built or were about build on the mainframe system. I concluded: </p><blockquote><p><i>The TRS-80 system in use now by San Bernardino Tool Control basically serves their need for the maintenance of inventory data. It is a simple alternative to the card file used by Irvine Tool Control for this data. However, the long-range use of the TRS-80 has serious limitations as outlined above.</i></p></blockquote><h3>Beginning of a Major Disruption in Enterprise IT</h3><div>Although I didn't realize it at the time, the world of corporate IT was changing. In reviewing an early version of this post, my manager, <a href="https://www.linkedin.com/in/rodgerbeard/" rel="nofollow" target="_blank">Rodger Beard</a>, offered this analysis (lightly edited). </div><div><div></div><blockquote><div><i>Our Smith Tool TRS-80 experience demonstrated a trend that was already unfolding regarding the nature of business computing. Dramatically cheaper computing hardware and operating system software had already started to come on scene with the introduction of mini-computers, from DEC and HP especially. But the TRS-80 and IBM's hurried, clumsy, poorly conceived PC initiative soon after had a far, far bigger impact. Mini- and micro-computers enabled the rapid movement away from the IBM computing castles that were then the norm, with budgets that only kings could afford. Because the dollars were so great and castles took so long to build (with high implementation costs and high risk of failure) there was a critical business need for better and cheaper ways to deploy automated business systems. The TRS-80 and then PCs offered a way to fulfill that need, and to work around IT departments that were mostly seen as being in the way. </i></div></blockquote><blockquote><div><i>That said, low-cost hardware was just the first leg of a 3-legged stool of disruptive technological innovations that would become manifest over the coming years. The second leg was the faster development time that these platforms offered to build business software. The TRS-80s at Smith Tool clearly demonstrated that software could be developed more cheaply, faster, and more easily, albeit with certain downsides that we, the knights guarding the IT castle, thought were important, but not as important to many in the business. </i></div></blockquote><blockquote><div><i>The point is that shadow IT was conceived as the direct solution to an already very well known problem. There was too high a cost, as well as too much delay and pent-up demand for business software. Packaged software suites, higher level and advanced programming languages, 4GLs like Focus, emerging SDMs, software engineering and coding being taught in public schools, software training as a industry, computer engineering majors offered on every college campus, H1b visas, outsourcing, and then offshoring, all were solutions intended to solve this problem. Net of it all, software cost is now tiny compared to when we found out about the TRS-80..</i></div><div><i><br /></i></div><div><i>The third leg of the new stool was obviously overcoming the primitive data communications networks of the time as well as costs and delays associated with creating node-to-node communications. The creation of the internet, and with it fast, cheap, available connectivity was the disruptive change that gave the new IT stool all three legs. (Wow did it ever!)</i></div></blockquote><div></div></div><div><h3><i>Lesson Learned: Bring Shadow IT out of the Shadows</i></h3></div><div>Rodger is right. Although my analysis of the TRS-80 system may have been correct in identifying its shortcomings, it took me a few more years to understand the bigger picture. When the business has a need and the corporate IT organization does not have the resources to meet that need, the business will find a way to solve the problem. The days when the IT organization could just say no, or wait until next year, were coming to an end. </div><div><br /></div><div>Ultimately, the technology disruption brought its own new set of challenges. For example, user departments purchasing or building their own software, were soon asking for the IT organization to connect them to corporate systems. Many IT leaders were understandably distraught with these requests when they were not involved in the original development or procurement of the shadow system. </div><div> </div><div>Over the years, the most healthy way to deal with shadow IT is to bring it out of the shadows. It is really a matter of IT governance. Best practices in dealing with shadow IT include having a multi-year IT strategic plan that addresses major needs throughout the organization, guidelines to determine which systems are best deployed by corporate IT and which can be left to end-user development, an overall enterprise architecture, and budgetary flexibility where in some cases the business funds new system development, with the IT organization delivering or managing the services. </div><div><i><br /></i></div><div style="text-align: left;"><b>Postscript:</b> My recollection is fuzzy concerning the events that followed. My personnel file indicates I finished implementing the corporate tooling inventory system in 1982, and I moved on to an even more interesting project. But this all took place just before the multi-year decline in oil prices and collapse in the US drilling rig count, which devastated Smith’s business. The San Bernardino plant was shut down, so the use of the TRS-80 system became moot. </div><h3 style="text-align: left;">End Notes</h3><p>[1] In reviewing the system specification I wrote for this project, I notice that I applied the lesson learned from <a href="https://fscavo.blogspot.com/2021/09/what-i-learned-from-waterfall-project.html">my previous project,</a> where we had a failure with the traditional waterfall development approach. In my system specification for this project, I wrote: </p><blockquote><p><i>“Because a project addressing all the known requirements for a tooling inventory system would take over one calendar year to develop, we have adopted a two-phase approach. This allows Manufacturing Services to receive benefits from the project within six months of product initiation. <u>It also allows us to evaluate the use and effectiveness of the system delivered in the first phase before beginning the second."</u> </i>[Emphasis added.] </p></blockquote><p>In other words, I was determined to test the users’ commitment to adopt initial capabilities of the new system before IT would spend the time and effort to develop the rest of it.</p><p>[2] When I started writing this post, I assumed that tooling inventory control systems would be commonplace today as modules within manufacturing ERP systems. Although <a href="https://blogs.sap.com/2019/04/29/basic-process-steps-of-tool-management-in-machine-shops/" target="_blank">SAP appears to have a solution</a>, I am hard-pressed to find many others, outside of a few point solutions. I have a feeling that many customers today manage tooling inventory as a special item type in the production bill of material, which may be adequate for many manufacturers, although this approach has its shortcomings. If readers have insights on this, please leave a comment on this post. </p><p>[3] RadioShack, founded in 1921, was a one-stop shop for all things electronic, from components to personal electronics to micro-computers. It essentially went out of business in 2015. The TRS-80, launched in 1977, was one of the first widely available microcomputers. </p><p>[4] As I wrote in my trip report, </p><blockquote><p><i>“The TRS-80 is a microprocessor, and it is not designed for large-scale business systems. It has limitations on file sizes and key lengths…. There are limitations in real storage…. The hardware is designed to be run only 8-10 hours a day. It is designed for the occasional hobbyist or for a light back-office business, not for the day-to-day operation of a heavy manufacturer.” </i></p></blockquote><p>Moreover, the user-developed tooling system was only intended to satisfy needs around tooling procurement and inventory control. There was no functionality for tooling bills of material (tool lists) or ability to associate them with production orders. In Irvine, we had already built a system to automate these functions on the mainframe, but San Bernardino de-automated those functions and put them back onto a paper-based system. </p><p><b>Image Credit </b></p><p>TRS-80. Attribution: <a href="https://www.flickr.com/photos/35448539@N00" rel="nofollow" target="_blank">Blake Patterson</a>. Source: <a href="https://commons.wikimedia.org/wiki/File:TRS-80_Model_4_(modified).jpg" rel="nofollow" target="_blank">Wikipedia Commons</a>.</p><div><br /></div></div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-3511056.post-41944877745439234662021-09-18T09:59:00.004-07:002021-09-19T14:28:09.637-07:00What I Learned from a Waterfall Project Failure<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://www.youtube.com/watch?v=auiq3IcmtLk" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;" target="_blank"><img border="0" data-original-height="805" data-original-width="1018" height="253" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhplYleE4qYbYmVrStaGQGQMm88WwTOywj1naWinI_PPAtc-qoizfTWBptrtHESUXu_cUc4q8jVMs47LROIC05gZJqqt8BwXsTfEJceylbatn4LZ7QUKVHpurg7ppNgfa8MP2zD/s320/Forge1.png" width="320" /></a></div>In my most recent post on lessons learned in my career, I covered <a href="https://fscavo.blogspot.com/2021/08/what-i-learned-at-smith-tool-about.html">my time as an IT employee at Smith Tool</a>. I learned so much in those years, and I need another few posts to cover some of the more interesting lessons.<p></p>By 1980, my work in manufacturing systems had been all in machining operations. Now Rodger gave me a new assignment, to develop a new system to support Smith’s forge plant. This opportunity took me upstream into the forge, which I was told was the largest forge in the United States west of the Mississippi<sup>1</sup>.<br /><br />As I noted in the previous post, I loved the nitty-gritty sights and sounds of the metalworking plant. But the forge was another whole level of physicality, almost violent. As you approached the forge, you could hear the hammer and feel the ground shake as the press hammered out parts<sup>2</sup>. And outside the plant were pallets of newly forged parts, still red hot to the point where you could not stand closer than 20 or 30 yards without feeling the heat. <br /><br />Here is a good <a href="https://www.youtube.com/watch?v=auiq3IcmtLk" target="_blank">video of a forge plant</a> that gives a sense for what it’s like to be inside one. The press in this video is smaller than the two at Smith. Also, our forge plant was more modern and the parts being forged in the video are different, but the sights and sounds are the same.<div><h3 style="text-align: left;">Forging Operations Are Tricky to Schedule </h3>Smith used a process called closed die forging. This means that the red-hot steel bar would be pressed into a die in the shape of the finished part. The tricky part is that the die would only be able to produce a given number of forgings before it had to be sent out for “resinking,” a sharpening operation, so that they could produce more forgings. The production scheduler used manual log books to keep track of how much life was left in each die and to know which dies had enough life left to fill an order. But if the log books were not updated correctly, the forge might not be able to meet its production schedule. This was the process the new system would automate, with the benefits of being able to better meet production schedules. <br /><br />The new system was described in a company newsletter after the project was (supposedly) completed.</div><blockquote><div><i>Simply stated, the Forge Die Tracking System keeps track of over 3,000 components that make up the 300 forge dies used to stamp out the various forgings to make Smith Tool’s products. Additionally, the system makes the die selections to fill each forge order according to which dies most closely match in wear and on the basis of how much life the dies have left. When the system notes that a die’s life is getting low, it will suggest to the scheduler that the die be used to make as many forging as is left in it to make, and then be sent out for resinking. So, while the order is being filled, the excess forgings being produced will go into inventory as safety stock.</i></div></blockquote><div>I was assigned as project manager and lead analyst six months into the project, which had stalled for lack of someone who could develop the calculations for picking the best set of dies for a given order, suggesting the optimum production quantity to “run out” the die, and to track dies sent out for resinking. <br /><br />I took it as a challenge. I remember distinctly that this was taking place during the run up to the US 1980 presidential election. So, I wrote my programming specifications with references to identifying candidate dies, nominating them, and then electing the best one. Although I had three programmers reporting to me for this project, I wrote some of that core scheduling logic myself.</div><div><h3 style="text-align: left;">The New System Installed but Not Implemented </h3><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5sv1OH83gTs7tMbeodaEJJb1wl57avZVlvvAI_9TBhC255QIEIzX7XGaQVJ8y6-JbtchQPt205iLkUkLKZ9sXF1braULGL4kb3r-d6RW79S-OaSpaGy4jJ7LdwoumDeSksYmr/s515/Waterfall_model.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="396" data-original-width="515" height="246" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5sv1OH83gTs7tMbeodaEJJb1wl57avZVlvvAI_9TBhC255QIEIzX7XGaQVJ8y6-JbtchQPt205iLkUkLKZ9sXF1braULGL4kb3r-d6RW79S-OaSpaGy4jJ7LdwoumDeSksYmr/s320/Waterfall_model.png" width="320" /></a></div>So, what went wrong? There is a little hint of the problem in the final paragraph of that newsletter story on the project:</div><blockquote><div><i>All the die structures <u>will be</u> on the system by the end of November. The history of all those components <u>will be</u> on by mid-December. The Forge personnel are enthusiastically anticipating the ease and efficiency the system will bring to the Forge operation. </i>[Emphasis added]</div></blockquote><div>Note the future tense.</div><div><br />Here’s how it went down. We put the system into production, and each week I would follow up with the director of forge operations to see how they were coming along with loading the die information. He had assigned this job to his administrative assistant, but the director told me she was too busy to get to it. After several weeks of follow up, it was clear that they had no intention of loading the master file data that the system would need to start scheduling the forge. The system became a very expensive piece of shelfware. I don’t recall how long they let the system continue to run in production without any data to process. But I was soon assigned to another development project. <br /><br />So, how did this project get approved in the first place? Later I found out that the forge director felt the IT department was spending all its time developing systems for the machining plant, and that it was “his turn” for a new system. The IT steering committee complied. <br /><br /><i><b>Lesson Learned: Test User Commitment through Phased Implementation.</b> This was my first real experience with the drawbacks of a waterfall development approach, where you define all the requirements up front, then design the entire system, then program it, test it, and deploy it. In this case, the users were happy to meet with us to provide their requirements and review our system design. But in terms of actually doing any real work, the users were off the hook until we put the system into production. At that point, they were not willing to let a low-level administrative assistant spend the time to do the necessary data entry, or hire a temp worker to backfill her regular duties so she could do so. <br /><br />After that I vowed never again. What we should have done is build the database and then have the users enter the master file data before we invested more time programming the scheduling logic—the really difficult part, where the bulk of the development hours would go. That would have tested the users’ commitment and saved several months of wasted effort. This was 20 years before the Agile Manifesto, but my software engineering courses at UCI had already taught me about Barry Boehm’s spiral development methodology, which in many ways anticipated Agile. If only I had the foresight and permission to take this approach. </i><br /><br /><b>Postscript: </b>In reviewing a draft of this post, the department manager at the time, <a href="https://www.linkedin.com/in/rodgerbeard/" target="_blank">Rodger Beard</a>, has further recollections. He writes (lightly edited):</div><div><blockquote><i>I felt at the time and actually still feel a sense of personal failure for allowing this project to unfold the way it did. Exactly the way you've described. A painful recognition, over many months, that good work was being completely wasted.<br /> <br /> This was my first experience with having pure politics result in a significant waste of IT resources. However, like you, I learned from it. An aside, at the time, I also felt this system was not well conceived. If it were well deployed, it could have had an excellent ROI. But with the caveat that additional, easy-to-avoid ongoing human capital investment would be necessary to make it pay off. A red flag really. <br /> <br /> I think you're spot on regarding how the requirement should have been addressed. This was definitely mine (especially) as well as [name withheld]’s leadership error. We knew it was an "it's my turn" situation. [Our leaders] had decided to throw the forge a bone to shut up the forge director. If only I had had the foresight to ask you to do what your article says should have been done. Sigh.</i></blockquote></div><div>Thanks again, Rodger, for your confirmation in this series. <br /><hr /><h3 style="text-align: left;">End Notes</h3><sup>1</sup>The forge was about 200 yards from the Smith Tool metalworking on Von Karmen Avenue in what used to be known as the Irvine Industrial Complex. Driving through that area today, now known as the Irvine Business Complex, it’s hard to believe there was such heavy manufacturing there into the 1980s. That part of Irvine is now mostly commercial offices and some distribution or light manufacturing facilities. The metalworking plant today is an Amazon distribution center. <br /><br /><sup>2</sup>The purpose of forging is to form the raw material into a part that has dimensions close to what is needed so that the first machining operation only needs to remove a minimum amount of metal. Forging also improves the metallurgical properties of the material. It is the same process as the ancient blacksmith employed with his hammer to make metal implements, such as horseshoes. In fact, Smith Tool began as a blacksmith shop in 1902 in Whittier, CA.</div><div><br /><b>Photo Credit </b><br /><br />Waterfall. The original uploader was PaulHoadley at English Wikipedia., <a href="https://creativecommons.org/licenses/by-sa/2.5" target="_blank">CC BY-SA 2.5</a>, via Wikimedia Commons</div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3511056.post-17879964642070303402021-08-28T12:01:00.011-07:002021-09-18T10:10:22.673-07:00What I Learned at Smith Tool about Enterprise IT<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXIBMO9L9vca6JeCZtmewedqLfYvdNOIHJJSfLUCEgMwe3tqN5m-CPV4xPVheNSqFxhcbZQfA54M3hkpom9gHAxEZvY4OmbIBE0tmjBesIt4dxv9TtZQNfnp43qX79-tMrpJRl/s640/rock-bit-derrick-floor.jpg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="640" data-original-width="454" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXIBMO9L9vca6JeCZtmewedqLfYvdNOIHJJSfLUCEgMwe3tqN5m-CPV4xPVheNSqFxhcbZQfA54M3hkpom9gHAxEZvY4OmbIBE0tmjBesIt4dxv9TtZQNfnp43qX79-tMrpJRl/s320/rock-bit-derrick-floor.jpg" width="227" /></a></div>This post continues my series looking back to lessons learned in my career, which started in 1974 <a href="https://fscavo.blogspot.com/2019/06/what-i-learned-at-macys-about.html">at Macy’s headquarters</a> in Manhattan and continued <a href="https://fscavo.blogspot.com/2021/06/enterprise-it-at-trw-credit-data.html">at TRW Credit Data</a> in California in 1976. This post takes me to the next step of my journey.<p></p>As noted in the first post, my goal is not just talk about how technology has changed. Everyone knows that. As incredible as those changes have been over my nearly half-century in the business, it is also fascinating how many things have <i>not </i>changed. Many of the lessons learned still apply today. That’s my focus.<div><h3 style="text-align: left;">Getting Restless </h3>Although TRW was a great learning experience, I only stayed there for about 18 months. I was getting bored with accounting systems, and I was looking for something where I could continue to develop new skills. I read in Computerworld that manufacturing systems were the next big thing, so in 1978 I started another job hunt. <br /><br />One of my interviews was with Smith Tool, a division of Smith International, an oil tools manufacturer in Irvine and, at the time, the third-largest employer in Orange County<sup>1</sup>. They made me an offer, and I accepted. In addition to being able to break into manufacturing systems, the fact that I might be able to somehow apply my degree in geology was also attractive<sup>2</sup>.<br /><br /><i><b>Lesson Learned: Take Charge of Your Career. </b>In the 1970s, our elders commonly advised us that the best way to get ahead was to settle down in a large company and stay for decades. Although that worked for some of my peers, it never resonated with me. I never waited for opportunities to come to me. I would rather be proactive and pursue new directions. For young people, today is no different. Always be thinking about what you need to continue your career development. If your current employer can give you that, great. If not, look elsewhere.</i></div><div><h3 style="text-align: left;">Thrown into the Deep End</h3></div><div>The entire IT department at Smith Tool was about 30 people, with 15 of us in application development<sup>3</sup>. The company’s systems ran on two IBM mainframes. The manager of the applications group was Rodger Beard, and he assigned me to the supervisor of manufacturing systems, Ken Ruiz. <br /><br />On my first day, Ken sat me down to give me a primer on manufacturing systems. I was totally clueless. Using a white board, he explained the concept of part masters, which defined inventory items—whether finished products, intermediate assemblies, or purchased parts. He also explained product structure records, which defined the relationship between part masters to form bills of material. The capabilities to manage these relationships required a special type of IBM database, known as BOMP (Bill of Materials Processor) and the newer <a href="https://en.wikipedia.org/wiki/DBOMP">DBOMP</a> (Database Organization and Maintenance Processor). He then went on to explain work centers and routings, which define manufacturing processes. <br /><br />Later that day we went out to lunch. I drove, with Ken and two other co-workers in the car chatting about something called “whip.” Finally, I asked, what is “whip?” Work-in-Process (WIP) was the answer. As I said, I was clueless<sup>4</sup>. <br /><br />The next day, Ken gave me my first assignment—to customize and implement the MRP module of COPICS<sup>5</sup>, which was written in IBM assembly language. This was my first encounter with any type of packaged software, although it wasn’t much more than collection of assembler source code known as an IBM Field Developed Program, which just meant that an IBM-er wrote it for some customer and now it was available to others. The IBM engineer who wrote it just happened to be assigned to Smith Tool. His name was Roly White<sup>6</sup>. <br /><br />My assembler skills were a bit rusty since I had only used them sporadically at Macy’s two years prior. But within a few weeks I had made the necessary modifications and even found a bug in Roly’s code. <br /><br />I absolutely loved manufacturing systems. They were so much more interesting than accounting systems. I looked forward to going up into the plant mezzanine for meetings with users. I would don my Red Wing steel toed shoes, safety glasses, and ear plugs, and take my time getting to and from the meeting so I could stand and watch row after row of multi-axis milling machines or modern CNC machines throwing metal chips on the floor<sup>7</sup>.<p></p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjTVigYUXWqX-xM0Bm25E70M_40Sf3h7hn4zy_1zJQC7W4mnlpdcunP3D1Cb4qnKlpOnrT0-v5bbA8stxoAZ_5KDrXyAdTQkxbyiT9Gimy9YwPjJsjmedr1JC63VxZ1aoN5Skp/s799/Factory-floor.jpg" style="margin-left: auto; margin-right: auto; text-align: center;"><img border="0" data-original-height="317" data-original-width="799" height="159" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjTVigYUXWqX-xM0Bm25E70M_40Sf3h7hn4zy_1zJQC7W4mnlpdcunP3D1Cb4qnKlpOnrT0-v5bbA8stxoAZ_5KDrXyAdTQkxbyiT9Gimy9YwPjJsjmedr1JC63VxZ1aoN5Skp/w400-h159/Factory-floor.jpg" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><i style="background-color: white; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13.2px;"><span style="font-size: x-small;">Not Smith Tool, but similar, and much smaller. </span></i></td></tr></tbody></table><div style="text-align: left;">My crash course in manufacturing was not limited to on-the-job training. Within a few weeks, Ken mentioned the monthly dinner meetings of Orange County APICS, the American Production and Inventory Control Society (recently renamed as the Association for Supply Chain Management, ASCM). About half of our department would attend each month, and the dinner meetings drew several hundred people. The legendary George Plossl spoke at one meeting and visited us at Smith Tool the next day, where he fielded questions. (I remember one on how to plan capacity for a heat treat operation.) I also enrolled in a four-course series of APICS certification classes at night at Cal State Fullerton, where we learned principles of inventory management, MRP, master scheduling, statistical forecasting, and other basic concepts. My favorite class was the final one, taught by Nick Testa, which tied everything together. Nick went on to become President of APICS International in 2006 and the chair of the APICS international conference<sup>8</sup>.</div><p><br />Within two years, I was APICS-certified at the Fellow Level, a real accomplishment for someone who only two years prior didn’t know what MRP or WIP stood for. <br /><br /><i><b>Lesson Learned: Build Your Industry Experience. </b>If you are going to be an expert in business applications, you need to build your industry credentials. For IT infrastructure, this is not as critical a requirement. But when it comes to applications, most employers favor those with industry specialization. This is even more critical for consultants. If you have experience in ERP systems for manufacturing companies, for example, that doesn’t translate to ERP in charitable organizations or hospitals. In the course of my career, I gained experience and credentials in several manufacturing sub-sectors, such as medical devices, pharmaceuticals, food manufacturing, and high-tech, among others. This doesn’t mean you can’t specialize in multiple industries, but don’t try to be a jack-of-all-trades.</i></p><p></p><h3 style="text-align: left;">Moving to the Front End of the Software Development Life-Cycle </h3><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2iLTbC_Id8w_ScqSMif4SMDPDfwc2RowKDELjBtCHa8Thp9svb1W_PacygJFZJd7TpdA-C5YoOLZm3tOIPYJveIKAjCSie9W7cDkMVm4oXdazI_pkLRjM6qdhB08g3kWZV5q5/s550/SDM.png" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img alt="SDM-70 Methodology Schematics" border="0" data-original-height="420" data-original-width="550" height="153" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2iLTbC_Id8w_ScqSMif4SMDPDfwc2RowKDELjBtCHa8Thp9svb1W_PacygJFZJd7TpdA-C5YoOLZm3tOIPYJveIKAjCSie9W7cDkMVm4oXdazI_pkLRjM6qdhB08g3kWZV5q5/w200-h153/SDM.png" width="200" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">SDM/70</td></tr></tbody></table>As noted in my earlier post, I was formally trained in software engineering during my time at TRW, mostly around system design, development, and testing. Soon after I arrived at Smith, the department standardized on an SDLC methodology called <a href="https://en.wikipedia.org/wiki/Cap_Gemini_SDM">SDM/70</a>. It consisted of about four feet of three-ring binders, with forms and instructions for each phase and step of the development process, from initial feasibility studies all the way to go-live and ongoing maintenance. Rodger made me the department coordinator. <br /><br />I understood the system design and development phases, but what really interested me was the earlier stages, like system requirements and especially business requirements. I wanted to get involved earlier and earlier in new projects, even to the point of helping decide whether a new system was even feasible, or whether there was a business case for it. <br /><br />Over the next five years, I led a number of interesting projects, with several important lessons learned—both positive and negative. But the most interesting project of all was a Bit Record Database system, where I led the development of a new system to track the current and historic downhole performance of drill bits in the field. This system would become a key focus of my career direction over the next eight years. And, as I recently discovered, it was a strategic initiative for the company at the highest levels. <br /><br /><i><b>Lesson Learned: Pick a Focus. </b>When it comes to enterprise IT, figure out where your interests really lie. No one can specialize in every aspect. Some of my coworkers went deep into coding, others enjoyed project management, others pursued a management path, while others, like me, wanted to get close to the business. This was another indication of where my career would be headed in the coming years, which included my leaving Smith’s IT department altogether and moving into the business itself. More on that in a future post.</i><p></p><p></p><h3 style="text-align: left;">How I Almost Missed This Career Opportunity </h3>My years at Smith Tool were my greatest period of professional development at this point in my career. But I came very close to missing out. Here’s the story. My first interview was with a low-level HR representative, who I arranged to screen me during my lunch hour. I was very eager to get past her and on to the hiring manager. Unfortunately, she kept me waiting for nearly an hour. When I finally got in to see her, my annoyance was visible and she decided not to pass me on for the next interview. After two or three weeks, my recruiter went back and somehow convinced the HR group to interview me again. This time, I behaved myself and got passed on to Rodger. I got the job. But, without this second chance, my career could have been much different. <br /><br /><i><b>Lesson Learned: Respect People at Every Level. </b>Everyone deserves tolerance and respect, from the front desk receptionist, to the warehouse worker, to the CEO. Moreover, you never know who has influence, and who can make or break your career. And, as my wife, Dorothy, points out, this lesson applies in all areas of life, not just the workplace. </i><br /><br />But now I have discovered there is another angle to this story. After reviewing the first draft of this post, Rodger gave me some new perspective from the other side of the desk, so to speak. He writes that his memory around how I was hired (or nearly not hired) is somewhat different than mine. He writes:<p></p><p></p><blockquote>As was often the case, here HR used a simple checklist of buzzwords they didn’t understand to screen candidates, rather than understanding the basic job requirements….HR didn’t want to and/or just didn’t know how to screen for (1) brains, (2) energy level with track record, and (3) integrity—what I was specifically demanding. HR would provide me two stacks of resumes each week. Your resume was in the “wrong” stack because of the buzzword score. But HR had not provided enough candidates, so we decided to bring you back in anyway, regardless of the scoring. You then answered my questions and clearly demonstrated you met my three fundamental requirements. I was pretty sure that we could provide the on-the-job training needed to close the application experience gap. That said, in all candor, I never expected that you would take the initiative that you did to close the gap to the extent that you did, as rapidly as you did. </blockquote><i><b>Lesson Learned: When Hiring for Key Positions, Understand What Really Matters. </b>A job posting today can bring in hundreds if not thousands of job applications. Modern recruiting systems, in response, can sort through them and prioritize them into electronic piles, like Smith’s HR group did with paper 40 years ago. Although we need some way to prioritize applicants, the process has to start by thinking through what really matters in qualifying a candidate—not just picking buzzwords. Fortunately, for me, I had Rodger sitting on the other side of the desk.</i><p></p><p></p><h3 style="text-align: left;">A Bump in the Road</h3>My employment at Smith continued until 1983, when it took a short detour due to the oil crisis and a massive layoff. I had been promoted into first-level IT management by that time. Although I was not part of the layoff, the head count reductions meant I needed to be demoted back to a systems analyst and project manager role. Even worse, that Bit Record Database project I was leading was put on hold due to the downturn. This was too much for me, so I reluctantly took a job offer from Gemco, a now-defunct membership department store, to go back to my retail industry roots. But I was only there for a few months when I got the call from Smith to come back to restart the Bit Record project. I agreed, but only if I could do so as an independent consultant. This launched my consulting career. More on this in a future post.</div><div><br /></div><div><b>Update</b>: For the next lesson learned from my Smith Tool days, see: <i><a href="https://fscavo.blogspot.com/2021/09/what-i-learned-from-waterfall-project.html">What I Learned from a Waterfall Project Failure.</a> </i><br /><p></p><p></p><h3 style="text-align: left;">Footnotes </h3><sup>1</sup>Smith Tool had an <a href="https://www.encyclopedia.com/social-sciences-and-law/economics-business-and-labor/businesses-and-occupations/smith-international-inc">interesting history</a>. The firm was founded in Southern California in 1902, a time when California rivaled Texas and Pennsylvania in the oil industry. (You can still see oil field pumps in parts of Orange and Los Angeles counties.) Smith started with fish tail bits but eventually began manufacturing three-cone rock bits, which had been invented by Howard Hughes, who founded Hughes Tool. In 1975, Smith tried to get two Hughes patents invalidated but lost the case in 1986 and was ordered to pay over $200M for patent infringement. Using my bit record database, I worked behind the scenes with Smith attorneys during that litigation, and my analysis was submitted in court. I may share more about this in a future post. Smith Tool, along with the rest of Smith International, was acquired by Schlumberger in 2010, and is now known as <a href="https://www.slb.com/companies/smith-bits">Smith Bits</a>. <br /><br /><sup>2</sup>In addition to the career opportunities, Smith Tool was only about five miles from our home in Irvine. With new baby Steve on the way and only one car, I bought a 10-speed and was able bike to work several days a week, which did wonders for my cardio-fitness. <br /><br /><sup>3</sup>When I arrived, the IT environment at Smith Tool was two IBM 3033 mainframes running IBM’s Disk Operating System (DOS). Smith was reportedly IBM’s largest customer running this lower-end mainframe OS. The only commercial software in the portfolio was MSA for payroll and HR. Everything else was custom batch systems, which had been developed by Arthur Anderson (now Accenture) several years earlier. Most of them had a similar design. I also began developing online (CICS) applications around this time. <br /><br /><sup>4</sup>In writing this post, it was hard for me to understand what Rodger saw in me. It must have been that the demand for manufacturing systems developers far exceeded the supply. They had no choice but to train them. I think it must have also been my academic credentials, along with my experience with both COBOL and assembly language (which would soon be needed). They were also interested in my experience at Macy’s with IBM’s DOS operating system and my experience at TRW with IBM’s high-end MVS operating system. In reviewing an early version of this post, Rodger confirms that all of these factors came into play and that my DOS/MVS experience was particularly attractive. Eventually, Rodger assigned me as the co-project manager for the company’s DOS to MVS migration. My co-PM was young systems programmer named Wayne Meriwether. Since then, Wayne and I have had many business relationships: He has been my client, we have been business partners at Strativa, and after he left Strativa, he came back as a subcontractor. He remains a friend and close associate. <br /><br /><sup>5</sup>I am having difficulty tracking the history of COPICS. Some sources indicate the product was announced by IBM in 1979. But I was working on the MRP module in 1978, near the beginning of the “MRP Revolution.” So, it might be that this field-developed program, written or customized by Roly was incorporated into COPICS. If so, my bug fix would have become part of the commercial product. <br /><br /><sup>6</sup>Even as a young man, <a href="http://ascm-oc.org/RolyWhite.htm">Roly White</a> was a remarkable character. When he would show up, we all stopped work to hear what he had to share. He was a short, wiry guy, with the standard-issue IBM white dress shirt—but always with an unbuttoned top button, his tie loose, and a cigarette dangling from his fingers. He became a pillar of the Orange County APICS community, where he served for many years. He passed away in 2016, and there is a <a href="http://ascm-oc.org/RolyWhiteDonate.htm">scholarship fund</a> in his name. <br /><br /><sup>7</sup>The larger milling machines could produce much greater volumes of parts, but they took several days to set up for each job. If you understand the relationship between setup time and lot size, you know what this means for inventory levels. The CNC machines could combine multiple operations in one quick setup, but they only produced one part at a time. Understanding these relationships led in a few years to the lean manufacturing movement, which followed the MRP revolution. Contrary to the belief of some, the two are not conflicting theories. <br /><br /><sup>8
</sup>Over the years, Nick Testa and I have had many business relationships. I have been his student, and after I got certified we went on to be co-teachers and co-developers of APICS curricula. Later we became co-workers running two system integration practices, and later he became a subcontractor to me at Strativa. He remains a friend to this day.</div><div> <br /><b>Photo Credits </b><br /><br />1. Creator: Robert Yarnall Richie. Credit: DeGolyer Library. <a href="https://picryl.com/media/republic-steel-reed-rock-bit-being-swung-to-derrick-floor-on-thread-protector-ae9188">Via PICRYL.</a> Note: the rock bit here is not a Smith Tool bit but that of a competitor, Reed. They are nearly indistinguishable. This one is a milled tooth bit, in contrast to the higher-end tungsten-carbide insert bits. <br /><br />2. CNC Machine Facility, <a href="https://commons.wikimedia.org/wiki/File:CNC_Machine_Facility.jpg">Wikimedia</a>. <br /><br />3. SDM2 Method, which is similar to that of SDM/70. <a href="https://en.wikipedia.org/wiki/Cap_Gemini_SDM#/media/File:SDM2.png">Wikipedia.</a><p></p><p></p><p></p></div><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><br />Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-3511056.post-15976364836663699872021-07-29T18:50:00.002-07:002021-07-29T18:52:10.285-07:00Amazon and Workday Part Ways on HCM <p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfuby-Hq0bhDvzzQhwVhiERIXdWZYvBV402KjPV8sxN7XmykZkuqGwQsW-lL27qKqeI5aenFOKkgf9ERpcpQEdOWo7FmTEKKd9jisSKE1O0YSy_PVF3rWwIcfgBEL7tsREj0Bk/s256/Workday_Headquarters.jpg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="172" data-original-width="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfuby-Hq0bhDvzzQhwVhiERIXdWZYvBV402KjPV8sxN7XmykZkuqGwQsW-lL27qKqeI5aenFOKkgf9ERpcpQEdOWo7FmTEKKd9jisSKE1O0YSy_PVF3rWwIcfgBEL7tsREj0Bk/s0/Workday_Headquarters.jpg" /></a></div>I missed the news earlier this week that Amazon and Workday called off the implementation of Workday HCM. Apparently this is only coming to light now, even though the project was abandoned more than 18 months ago. How something this big was not leaked earlier is a mystery. <p></p><p><a href="https://diginomica.com/amazon-punts-move-workday-hcm-whats-takeaway-customers">Phil Wainewright</a> has a thoughtful post on the subject. He writes: </p><blockquote><p><i>Questions remain concerning e-commerce giant Amazon's discontinuing of its wholesale deployment of Workday HCM and Payroll, which came to light this week after a <a href="https://www.businessinsider.com/amazon-ends-deal-workday-hr-software-partnership-2021-7?r=US&IR=T#https://www.businessinsider.com/amazon-ends-deal-workday-hr-software-partnership-2021-7" rel="nofollow">report in Business Insider</a>. Workday subsequently published <a href="https://blog.workday.com/en-us/2021/clarifying-amazon-workday-deployment.html">a blog post confirming</a> that the two companies had "mutually agreed to discontinue" the deployment more than a year and a half ago, which was over three years after Amazon first signed up to the deal in October 2016. The deal was announced in February 2017, shortly after Workday announced retail giant Walmart as a customer, a deployment that has since successfully gone live.</i></p></blockquote><p>On a positive note, the project is ending without litigation. And, according to Workday's blog post, it will continue its partnership with Amazon's AWS for its cloud infrastructure, as well as its implementations with other Amazon subsidiaries, such as Audible, Twitch, and Whole Foods. </p><h3 style="text-align: left;">What Happened? </h3><p>The Business Insider report, based on an anonymous source, says "the database behind Workday's software didn't scale as planned to fully support Amazon's rapidly growing workforce."</p><p>Workday disputes this. It writes: </p><blockquote><p><i>This was not related to the scalability of the Workday system, as we
currently support some of the world’s largest organizations, including
more than 45% of the Fortune 500 and more than 70% of the top 50 Fortune
500 companies. In addition, more than 70% of our customers are live,
including one of our largest customers — a retailer — across its more
than 1.5 million global workers.</i></p></blockquote><p>Workday, rather, <a href="https://blog.workday.com/en-us/2021/clarifying-amazon-workday-deployment.html">writes</a> that the project failure has to do with Amazon having a "unique set of needs that are different from what we're delivering for our broader customer base." It also writes, "At times...customers have a unique set of needs that are different from what we’re delivering for our broader customer base, as was the case with Amazon — one of the most unique and dynamic companies in the world." </p><h3 style="text-align: left;">How Do I See It? </h3><p>All I can do here is read between the lines. </p><p>First, I don't think the Business Insider's claim of a Workday scalability problem is credible. Workday doesn't name its large retail customer, but no doubt it is Walmart. In 2020, Amazon had about 1.3 million employees, while Walmart had about 2.3 million. So, as my late business partner used to say, there is "an existence proof" for Workday being able to scale to support enterprises with multi-million employee counts. </p><p>Then, what about Workday's claim that Amazon had some unique requirements that are different from what Workday provides for the rest of its customers? </p><p>This has a ring of truth to it. Amazon is unique in many ways, and it would not be surprising if this extends to how it hires, retains, and manages its workforce. As a SaaS provider, Workday cannot afford to customize its core architecture and process to accommodate a single customer, even one as large as Amazon. It is commendable that Workday was willing to walk away from a large opportunity like this rather than compromise its core architecture. </p><p>On a much smaller scale, <a href="https://www.plex.com">Plex </a>(a cloud manufacturing ERP provider), in its early years, used to make customer-specific customizations to its core multi-tenant code base. Later, it paid the price to move those customers off those customizations and back to its common core. To my knowledge, it is still trying to do so. Workday is not about to make that mistake. (Interestingly, Plex itself is a Workday client and partner.)</p><h3 style="text-align: left;">What Happens Next? </h3><p>Workday writes that it and Amazon may revisit the HCM deployment in the future. But for now the project has been discontinued. This leaves Amazon on its legacy Oracle PeopleSoft HCM system. </p><p>This is where the plot thickens. There is no love lost between Amazon and Oracle. With its Redshift offering, Amazon looks to shift Oracle customers away to Amazon's data warehouse. Oracle, in turn, looks to compete with Amazon with its own cloud infrastructure offering. Naturally, Amazon has been working to disentangle itself from any use of Oracle products in its internal operations. Having to remain on PeopleSoft has to stick in the craw of Jeff Bezos. This might explain why the project may be revisited in the future. </p><p>There are not many HCM options for enterprises the size of Amazon. PeopleSoft is a legacy platform, with Oracle's HCM Cloud as its successor. But Amazon is not likely to increase its dependence on Oracle. Workday is the obvious alternative, which is why, despite the project failure, it still might be "revisited. </p><p>So, is SAP an option?</p><p><span></span></p><a name='more'></a><p style="text-align: left;"><span style="font-size: x-small;">Photo Credit: </span><a href="https://creativecommons.org/licenses/by-sa/4.0"><span style="font-size: x-small;"> Coolcaesar, CC BY-SA 4.0, via Wikimedia Common</span>s</a></p><p></p>Unknownnoreply@blogger.com7tag:blogger.com,1999:blog-3511056.post-65859451556730932882021-06-27T13:07:00.015-07:002021-07-31T10:51:50.169-07:00What I Learned at TRW Credit Data about Enterprise IT<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJV6j6vRwshN8BtrIJ420GKMgIQznPfJ2czMnXRvfNJJV5BUP22fqtavZiJJNhJSOn93DqkX68_ax7CC2WxBND6_FThL4lakV8ZFi9io1yL0rp6gEpUlSo_DRGaRTiO2dZ9b8j/s705/TRW1-DiskDriveFarm.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="TRW Credit Data disk drive farm" border="0" data-original-height="447" data-original-width="705" height="203" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJV6j6vRwshN8BtrIJ420GKMgIQznPfJ2czMnXRvfNJJV5BUP22fqtavZiJJNhJSOn93DqkX68_ax7CC2WxBND6_FThL4lakV8ZFi9io1yL0rp6gEpUlSo_DRGaRTiO2dZ9b8j/w320-h203/TRW1-DiskDriveFarm.png" width="320" /></a></div>This post continues my look back at lessons learned from my career in enterprise IT. My first such job, at Macy’s headquarters in New York City, came to an end in late 1976 when Dorothy and I, now with an infant daughter, Susanna, moved to Southern California. <p></p><p>In <a href="https://fscavo.blogspot.com/2019/06/what-i-learned-at-macys-about.html">that first post</a> I shared how, starting as a trainee, I eventually took over support for Macy’s daily credit card billing cycle. I was also responsible for the export of customer information for monthly submission to TRW Credit Data. Now known as Experian, it was and still is one of the three major consumer credit reporting services in U.S. When I announced my decision to relocate to Southern California, my primary user manager, the Accounts Receivable director, graciously offered to pass my name on to his sales rep from TRW Credit Data, which just so happened to be based in Orange County. </p><div><div>That referral turned out to be critically important. When I arrived in SoCal, I started responding to classified ads and had three job offers within two weeks.<sup>1</sup> But the offer from TRW was the best. Some months later, my new manager, Rick Range, told me, “I don’t know what kind of pull you had back at Macy’s, but our sales rep was pretty insistent that I had to interview you.” </div><div><br /></div><div><i><b>Lesson Learned:</b> Value every business relationship. You never know which ones will be instrumental in the future. And, be sure to “pay it forward” whenever you can. Today, LinkedIn and other social networking sites make it easy to stay connected, but too often we still do not maintain those relationships. <br /> </i></div></div><h3 style="text-align: left;">One of the World’s Largest Data Centers</h3><div><div>At the time I was hired, the offices and data center of TRW Credit Data (officially, Information Systems & Services, or IS&S) were in unmarked buildings on Katella Avenue in Anaheim.<sup>2</sup> The data center then was one of largest in the world in terms of storage. Maintaining credit history on over 200 million Americans took a lot of disk drives in those days. The photo at the top of this post (<a href="https://www.experianplc.com/media/1323/8151-exp-experian-history-book_abridged_final.pdf" target="_blank">source</a>) shows the disk drive farm from the early 1980s, a good five to eight years after I worked there, but it gives a sense of how enormous it was. At the time I was there, there was one IBM mainframe and one Amdahl plug-compatible machine, to maintain some balance of power with IBM. </div><div><br /></div><div>It was such an impressive site that it served as a location for the 1985 film <i>Prime Risk</i>. The screen shot below is from that film. <br /> </div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgp1SN3y4cUELDzdr2xaB4PjpQUJd-LCUGmPvNfzjfrtbpSEFOjdvKfpcY0-60nEXknQV0ZX8cEMByQlcDzEHjFtiVThYJfZWIJIAA3e61gfSLso-ghGHoTb0qBaz7QsfHsxh81/s1832/TRWPrimeRisk9.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1025" data-original-width="1832" height="224" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgp1SN3y4cUELDzdr2xaB4PjpQUJd-LCUGmPvNfzjfrtbpSEFOjdvKfpcY0-60nEXknQV0ZX8cEMByQlcDzEHjFtiVThYJfZWIJIAA3e61gfSLso-ghGHoTb0qBaz7QsfHsxh81/w400-h224/TRWPrimeRisk9.png" width="400" /></a></div><div> </div></div><div><h3 style="text-align: left;">Dumpster Diving</h3><div>On my first day, Rick gave me a facility tour, including a walk through that data center. But there was an unusual stop on the tour. Rick took me out behind the data center to the loading dock, where there were several large dumpsters filled with green bar computer printouts to be scrapped. They all had locks on them. He explained that, in the past, criminals had searched through those dumpsters and had obtained access credentials into TRW’s consumer credit database, which they used to steal credit card numbers. This led TRW to secure those dumpsters. </div><div><br /></div><div><i><b>Lesson Learned: </b>Everyone in the enterprise must be security-minded. Many people think IT security and identity theft only became a problem with the dawn of the Internet. Not true: It was a problem back in the 1970s, and TRW took active countermeasures against it. Security not only included technical measures, but also physical security, such as securing dumpsters. Moreover, it was not just outsiders who were a threat. The company was highly sensitive to insider threats—employees inappropriately accessing credit reports, either out of curiosity or for more nefarious reasons. The system monitored all access and audited which employees accessed which credit reports. If you accessed a credit report for no legitimate reason you could be fired on the spot. <br /> </i></div><h3 style="text-align: left;">A Theoretical Foundation in Software Development</h3><div>Because of my experience with accounts receivable, Rick assigned me to the subscriber billing system, which was written in COBOL. I also developed new systems for sales reporting and a new system to handle billing for a new credit reporting system acquired by TRW. As I’ll note shortly, I was only at TRW for about 18 months, but I wrote a lot of software.<sup>3</sup> </div><div><br /></div><div>It was also a great place to develop my programming and software design skills, with courses taught in house. I also enrolled in several graduate courses at the University of California Irvine (UCI), which was and still is one of the top schools in the country for computer science. It was also convenient, being only about a mile from our home. </div><div><br /></div><div>My favorite course was Introduction to Software Engineering, taught by <a href="https://www.cc.gatech.edu/people/peter-freeman" target="_blank">Peter Freeman</a>, who later went to Georgia Tech the become the Founding Dean of the College of Computing. Despite the name, the course was anything but elementary. We covered the work of software luminaries such as Ed Yourdon, Daniel Teichroew, Ed Dijkstra, B. H. Liscov, Michael Jackson, Grady Booch, Fred Brooks, and Glenford Meyers. Professor <a href="https://en.wikipedia.org/wiki/Barry_Boehm" target="_blank">Barry Boehm</a> came down from Los Angeles to give one guest lecture—coincidentally he also worked for TRW, in its Defense Systems Group. <br /><br /></div><div><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVdzBh6ZqzqA-8SF26hQfbaITv_uD-hA6sI6gf0ehHy6Ign5C4uYg3pPGTxBTDIx5AmQk8upIq9ClqKaRjuNLi-p1G3H4-V4o-xcWNYJPFj7geREMawOuEkeORV82B3wvSeFBc/s640/TRWATOMStermpaper.jpg" style="clear: right; display: inline; float: right; margin-bottom: 1em; margin-left: 1em; text-align: center;"><img border="0" data-original-height="480" data-original-width="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVdzBh6ZqzqA-8SF26hQfbaITv_uD-hA6sI6gf0ehHy6Ign5C4uYg3pPGTxBTDIx5AmQk8upIq9ClqKaRjuNLi-p1G3H4-V4o-xcWNYJPFj7geREMawOuEkeORV82B3wvSeFBc/s320/TRWATOMStermpaper.jpg" width="320" /></a>The course ended for me on a high note. The final class exercise was to take one of the methodologies we had learned and apply it to a theoretical project. But I had a real project assignment from work—to develop a system to maintain accounting tables for the billing system—and I decided to apply three of the techniques (i.e., HIPO, Structured Design, and Jackson Design) to develop the system. I scored an A+ on the project, and Dr. Freeman wrote to me, in part: </div><div></div><blockquote><div><i></i></div></blockquote><i></i><blockquote><i>An outstanding project! This project shows much thought and care in its preparation. This perhaps is because you intend to implement the system. </i><br /><blockquote style="text-align: left;"></blockquote><div style="text-align: left;"><i>I was most interested in your use of different design techniques depending on what stage of design development you were at. This is quite an innovation. Also, as your critique reveals, this choice gave you the opportunity to evaluate the utility of each of the design techniques used. Impressive. </i></div><blockquote><div><i></i></div></blockquote><p><i>Keep up the good work (and ask for a raise). </i></p></blockquote><p><i></i></p><div>After this class, I was so thirsty for knowledge I applied and was accepted in UCI’s Master’s program for computer science. But with a full-time job and one-year-old Susanna at home, it was more than I could handle, and I never enrolled. Still, I continued to take other classes over the years. </div><div><br /></div><div><i><b>Lesson Learned:</b> Never stop learning. Many of the principles underlying today’s best practices in software development have their roots in principles we learned in those years. For example, object orientation is consistent with Structured Design principles of <a href="https://en.wikipedia.org/wiki/Cohesion_(computer_science)" target="_blank">cohesion</a> and <a href="https://en.wikipedia.org/wiki/Coupling_(computer_programming)" target="_blank">coupling</a>. Although the Agile Manifesto was decades in the future, it had a precursor in Barry Boehm’s promotion of <a href="https://www.techuz.com/blog/what-is-sdlc-spiral-model/" target="_blank">spiral development</a>. And, as I continued my studies, I found myself more and more interested in moving my focus earlier and earlier in the software development process, from coding to system design, to functional design, and to business requirements. This would be a sign of where my career would be heading.<br /> </i></div><h3 style="text-align: left;">Large Scale Project Management</h3><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIwFSl2uKsoIKgCC_jyZYl5KCLMzZungrmUXH8H8JIm9X-H4IDnjLZ9zC9MSqgXdgUleujW0jtZxYsJ0WMSIPa5sBhH4Q94FP7GYfdAblrn-O6kRY-JgOXfs4EPvEyYKpUp2A0/s682/TRWPrimeRisk1a.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="TRW tape library" border="0" data-original-height="381" data-original-width="682" height="179" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjIwFSl2uKsoIKgCC_jyZYl5KCLMzZungrmUXH8H8JIm9X-H4IDnjLZ9zC9MSqgXdgUleujW0jtZxYsJ0WMSIPa5sBhH4Q94FP7GYfdAblrn-O6kRY-JgOXfs4EPvEyYKpUp2A0/w320-h179/TRWPrimeRisk1a.png" width="320" /></a></div>There is another interesting chapter in the history of TRW Credit Data. As noted earlier, its consumer credit database was one of the largest in the world. In fact, it was so large that we actually needed three databases to cover the U.S.—with an East Coast, Midwest, and West Coast database. </div><div><br /></div><div>But now, imagine what needed to happen when a consumer moved from one region to another. The system had to move that consumer’s records from one database to another. For this reason, and others, there was a process at the time called “Reorg” that had to run, I believe, weekly. In fact, it took the whole week—when the data center finished one reorg, it started the next one. It was a burdensome tape-oriented process. The 1985 film<i> Prime Risk</i>, mentioned earlier, has one scene as shown in the screen shot nearby, which shows row after row after row of the enormous tape library. </div><div><br /></div><div>It soon became evident that the entire consumer credit database would need to be rewritten. The project had just been launched when I started with TRW in 1976, under the unassuming name “Project Rewrite.” Shortly thereafter, management gave it a new name, “Project 78.” The reader may guess what the 78 stood for. In any event, the project was was suspended until it was restarted in 1994 as Project Copernicus and completed in 1996 under the project name File One, with a $110M budget and 400+ person project team. As I understand it, the big reason the project was finally completed was that it was a contingency for the leveraged buyout that allowed TRW to spin off the business as Experian.<sup>4</sup> </div><div><br /></div><div><i><b>Lesson Learned.</b> Manage the schedule. The number one reason projects exceed their budgets is because they do not meet their schedules. Conversely, spending what it takes to push a project over the finish line can be a better choice than letting a project run unconstrained in its schedule and not delivering on its objectives. It also helps when there is a critical business need with no other option, as was the case here. A decades-long project schedule slip is unusual, of course, but the principle applies to more typical projects. <br /> </i></div><h3 style="text-align: left;">Time to Branch Out from Accounting Systems</h3><div>As noted earlier, I only stayed at TRW for about 18 months. I was still young in my career, and I was itching for a place where I could continue to develop new skills. Accounting systems were getting boring to me, and I read in Computerworld that there were opportunities in manufacturing. So, I started another job hunt. But that will need to wait for the next chapter. </div><br /><hr /><h3 style="text-align: left;">Footnotes</h3><div><sup>1</sup>Cross country job hunting in 1976 was nothing like it is today. There was no internet, no online job boards, email, or video conferencing. When Dorothy and I decided to relocate, my only information regarding job opportunities was the classified ads in the Los Angeles Times, which I managed to pick up at a NYC newsstand. That at least gave me an idea of what kind of jobs were out there and where they were located. But no employer in SoCal was going to consider, sight unseen, a programmer/analyst candidate with less than three years’ experience from across the country. So, the job hunt really couldn’t begin until I physically relocated. </div><div><br /></div><div><sup>2</sup>The office building had originally been some sort of motel, and there was an open courtyard in the middle with palm trees. <a href="https://en.wikipedia.org/wiki/Muzak" target="_blank">Muzak</a> was piped throughout the facility. It was quite a pleasant environment, far from the hustle and bustle of Manhattan. The office building and data center were unmarked, and for good reason. Consumers who had been denied credit based on TRW reports had been known to enter TRW offices and threaten employees. I shared an office, which had originally been a motel room, with another co-worker, <a href="https://www.linkedin.com/in/ken-romans-4105b59/" target="_blank">Ken Romans</a>. He was working on the core credit data system and had (and still has) much deeper technical skills than I did. Within the first year, TRW moved the offices from the converted motel to a new midrise office building in The City in Orange. But the data center continued on Katella until 1992, when TRW moved it to Texas.</div><div><br /></div><div><sup>3</sup>In an interesting twist, a family friend worked at TRW decades later. She told me that, during their work remediating the Y2K problem, she heard developers refer to a program as “so old, it must be one of those written by Frank Scavo.” I wonder if any of those programs are still in production. </div><div><br /></div><div><sup>4</sup>There is another twist to this story. The program director who eventually took File One over the finish line was Don Miller. Don was a close friend and associate of Dan Husiak, who came to work for me in 1998 and in 2000 became my business partner and co-founder of Strativa, our management consulting firm. Don became one of our trusted advisors. As a result, other ex-Experian executives came into my network, including Michael Scharf, Don Lavoie, and Will Sproule.</div></div>Unknownnoreply@blogger.com5Orange, CA, USA33.7879139 -117.85310075.477680063821154 -153.0093507 62.098147736178845 -82.6968507tag:blogger.com,1999:blog-3511056.post-75706304041412409202021-06-13T17:21:00.005-07:002021-07-26T11:58:12.265-07:00A Personal Experience of Lateral Thinking <p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyYF_qGA6Lm_QJu4CCIwkms4JrKqRx92ZwtXKaj9Zmdo9invP6m3_dhwQYkyZ0TpAVxGf_CF6tV8mIZG32zyhU9En9mF6VxO0IPcalrgTYUuCr0Q4BN3kEElw4zcl3YR77Sz96/s318/Pluto.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="Pluto, dog" border="0" data-original-height="318" data-original-width="313" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgyYF_qGA6Lm_QJu4CCIwkms4JrKqRx92ZwtXKaj9Zmdo9invP6m3_dhwQYkyZ0TpAVxGf_CF6tV8mIZG32zyhU9En9mF6VxO0IPcalrgTYUuCr0Q4BN3kEElw4zcl3YR77Sz96/w197-h200/Pluto.png" width="197" /></a></div>I missed the news earlier this week of <a href="https://newsbook.com.mt/en/edward-de-bono-passes-away-aged-88/" target="_blank">the death of Ed de Bono</a>. De Bono was the father of lateral thinking, a framework for creative thinking. <a href="https://en.wikipedia.org/wiki/Edward_de_Bono" target="_blank">Wikipedia</a> has a decent outline of his ideas and influence. <p></p><p>De Bono was one of the authors that most influenced my consulting career. I adopted many of his tools, most of them quite simple, in analyzing business problems and coming up with creative solutions. The tools are especially useful in facilitating groups. I only regret that I have not applied his methods more consistently in client engagements and even in my personal life. </p><p>One of my favorite tools is the <i><a href="https://creativiteach.me/creative-thinking-strategies/random-input/" target="_blank">random word stimulation</a></i>, which is great for brainstorming sessions. Simply put, when you are trying to come up with ideas that are "outside the box," you generate a random word (e.g., pick it out of a dictionary) and use that word as a jumping off point to come up with new ideas. The key, as always with brainstorming, is not to look for ideas that make sense, just generate as many as you can. When you run out of ideas, do another random word, and another. As with any kind of brainstorming, no judgment of the ideas is allowed. Save that for a later step. </p><div style="text-align: left;">In explaining this method, I like to point to one experience from a consulting engagement many years ago. My late business partner, Dan Husiak, was leading a client engagement to develop a new business strategy for a division of what was, at the time, one of the largest health plan providers in the U.S. We had scheduled a brainstorming session the next day, and Dan assigned me to facilitate the session. The objective was to come up with some new out-of-the-box ideas for new products or lines of business. </div><p>I suggested we use random word stimulation and explained how to do it. Dan didn't like it. </p><p></p><blockquote><p>Dan: <i>You mean you just pull out some random word, like "Pluto?" </i></p><p>Me: <i>Okay, good example. Do you mean Pluto the planet, or Pluto the cartoon character? </i></p><p>Dan: <i> I don't know, just "Pluto." </i></p><p>Me: <i>Okay, let's think about this. Pluto the planet. It's small, it's far out. We need far-out ideas. Not much there. Now, Pluto the dog. He's a dog. He's an animal. He's a pet. Hey, we can offer health insurance for pets! </i></p></blockquote><p><i></i></p><p>That was enough to let Dan give me permission to try it the next day. </p><p>The brainstorming session was a success. In fact, at the beginning of the session, I used the "Pluto" story as an example of how to use random word stimulation. After a couple of hours, the client project team had come up with a number of promising new ideas--enough for us to start evaluating them the next day. </p><p>The best part of this story is that at the end of the session, the top executive for the firm's Medicare HMO product line came up to me and said, "I want to talk to you about that pet insurance idea. You know our seniors love their pets, and pet ownership correlates with positive outcomes. We should look into how to offer a pet HMO." </p><p>Keep in mind, this was before health plans for pets were a widespread practice. </p><p>Thinking tools like random word stimulation are not only effective in creative thinking and problem solving. They are also fun. </p><p>Ed de Bono will be greatly missed. But fortunately he left the world with a long list of books, courses, and other publications for learning how to think. A good place to review them is <a href="https://www.edwddebono.com/" target="_blank">his website. </a></p><span><a name='more'></a></span><p><span style="font-size: x-small;">Image credit: By Disney - https://www.donaldduck.nl/duckipedia/p/pluto/ (this is the Dutch website for Donald Duck Weekblad and other Dutch publications, not a wiki), Fair use, https://en.wikipedia.org/w/index.php?curid=6644756</span></p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3511056.post-20071125913066750392021-03-18T17:14:00.004-07:002021-03-19T14:06:58.985-07:00Enterprise Buyers Not Looking for a One-Stop Shop<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7Y-tEpGlUiNVEGdOFZkK0oOOMqwu2ZCncd5mOTMc7puCNse6GtoWJSE33hNBYAY4utDGbPM45-TNmTfcsOQqkKVbKVEo_1XVgbhcislEkqFFIcBOJhxptt3bwZ_yakKZJ9NAm/s1024/OneStopShop.jpg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="1024" data-original-width="768" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7Y-tEpGlUiNVEGdOFZkK0oOOMqwu2ZCncd5mOTMc7puCNse6GtoWJSE33hNBYAY4utDGbPM45-TNmTfcsOQqkKVbKVEo_1XVgbhcislEkqFFIcBOJhxptt3bwZ_yakKZJ9NAm/s320/OneStopShop.jpg" /></a></div>There's been an interesting discussion on Twitter over the past few days, which I started with this deliberately ambiguous tweet. <p></p><blockquote><p><i>IMO, very few enterprise buyers are really looking for a "one-stop shop." </i></p></blockquote><p>As intended, that brought out replies from several friends and associates, such as <a href="https://twitter.com/vijayasankarv">Vijay Vijayasankar</a>,<a href="https://twitter.com/olivermarks"> Oliver Marks</a>, <a href="https://twitter.com/holgermu">Holger Mueller</a>, <a href="https://twitter.com/ghostinthenet">Jody Lemoine</a>, <a href="https://twitter.com/ShaneBryan_IT">Shane Bryan</a>, <a href="https://twitter.com/applebyj">John Appleby</a>, and others. </p><p>So, what did I learn from the dialog? </p><p>First, I was thinking back to client meetings I've sat through over the decades, where business leaders positioned "one-stop shop" as a key element of their desired strategy. </p><p>In other words, in the market we serve, customers are typically looking for 10 things. But today, we only offer seven. If we can offer all 10 things, we can become a one-stop shop! Customers will not have to go anywhere else but will have the convenience of having us satisfy all their needs. </p><p>In enterprise software, this might translate to an ERP system vendor attempting to offer a CRM system or supply chain management suite, or product data management, or a host of other complementary products. Invariable, because these systems take years to develop from scratch, in practice this means acquiring those complementary products. It may also mean offering other elements of a complete solution, such as a development platform, tooling, system integration services, even databases or hardware. </p><p>I don't know if Oracle ever used the term "one-stop shop," but it certainly behaved as if it had. It has been on a multi-decade acquisition spree, not only in business applications, but also in databases (its roots), infrastructure software (BEA), even hardware (Sun). To be fair, it also plowed profits from those products into new development, such as for its Fusion cloud applications. And it is now competing with Amazon for cloud infrastructure services. It is a poster child for the one-stop shop. </p><p>SAP has had its own version of the one-stop shop, acquiring a variety of systems (Holger calls some of them the seven sisters). It also built its own proprietary database, and it also has its own development tooling. </p><h2 style="text-align: left;">What About One Throat to Choke? </h2><p>One can imagine why such a strategy might be attractive to technology sellers. But is it attractive to technology buyers? </p><p>I say, no. In decades of consulting, I don't think I've ever heard a client say, I just wish I could buy everything I need from a single vendor. What I need is a one-stop shop. </p><p>But isn't a one-stop shop the same as "one throat to choke?" I say no. One throat to choke means that in a system implementation, for example, there is a prime contractor or service provider ultimately responsible for delivery. If another partner in the deal is not meeting its commitments, the prime contractor or service provider serving as overall program manager is responsible. It doesn't mean that there is only one service provider or vendor in the deal. </p><h2>What About Integrated Suites? </h2><p>Holger asked, "Are you saying that [integrated] suites are done?" Not at all. But I have two responses to this. First, many integrated suites are anything but. Especially if, as noted above, the vendor built its suite from piece parts that it acquired over time. It takes years to integrate software acquired from various sources. So, buying from a vendor attempting to be a one-stop shop does not ensure you are really getting an integrated suite. </p><p>Second, I have seen very few large deals where there was only a single software provider in the deal. There are almost always complementary products whether they be for sales tax reporting, factory data collection, data analytics, or countless other niche requirements. </p><p>Third, no IT organization's application portfolio only has software from a single vendor, not even a handful of vendors. Even small companies buy software from dozens of vendors. There is no one-stop shop in enterprise software. </p><h2>What About Application Rationalization? </h2><p>But what about vendor consolidation? Maybe one vendor isn't reasonable, but isn't it a good idea to limit the number of software providers and rationalize the applications portfolio? Certainly, many companies need to consolidate applications, especially if they grew through mergers and acquisitions and now have two, three, or more ERP systems, for example. </p><p>But that does not mean they need to only buy from one vendor. </p><p>Vendors love to talk about vendor consolidation, as long as the surviving vendor is them. They call this gaining in their "share of wallet," as in the buyer's wallet. </p><p>In my view, when it comes to vendor consolidation you can have too many vendors and you can also have too few. You don't want to have so many vendors that you have redundant types of systems. On the other hand, you don't want to have too few vendors to the point that they gain leverage over you. </p><p>To this point, I've heard of customers engaging in multi-year programs specifically to reduce dependence on certain Tier I vendors, as they become too powerful and attempt to engage in <a href="https://diginomica.com/book-review-real-deal-technology-deal-making-2020s">wallet fracking,</a> as my friend Brian Sommer calls it. </p><p>Is there a way to have the benefits of integration and applications rationalization without becoming overly reliant on a single vendor? I think there is. Modern cloud systems have become API-oriented. And to be fair, the major vendors, even those aspiring to a greater share of wallet, are building with this model. They have to, if they want market acceptance. Cloud leaders, such as Salesforce, do it by providing a platform that partners can write to, even leveraging Salesforce objects, to provide that integration. Oracle's NetSuite offers a similar capability. Cloud ERP vendors, like Acumatica, Plex, and Sage Intacct are very integration-friendly. Oracle's cloud applications and SAP's offer open APIs, as does Workday. Microsoft has similar capabilities. </p><p>If this is the future, then maybe vendors will give up the strategy of the one-stop shop. </p><p><span></span></p><a name='more'></a>Photo Credit: <a href="https://www.flickr.com/photos/marcemarc/2385399277" target="_blank">Flikr</a>. <a href="https://creativecommons.org/licenses/by-nc-sa/2.0/" target="_blank">License</a>. <p></p><p> </p>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-3511056.post-87556721934336055122021-03-10T16:02:00.009-08:002021-03-12T08:40:51.329-08:00Deploying Low-Latency Applications in the Cloud<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirGEDgQjxPf01-KJX-B0G-u5XiTWZa0dl8rZJoycuag3kFgFnbR8UYqexG-EX5mKh9-Rhh-0yNlsRBIEK6okDwiUVb_XulmbQoXcCQ0fMAXQU6llk2R7w-jw9gbpjbHwfjRUtw/s397/Thai-Summit-Plex-KORS-small.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="222" data-original-width="397" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirGEDgQjxPf01-KJX-B0G-u5XiTWZa0dl8rZJoycuag3kFgFnbR8UYqexG-EX5mKh9-Rhh-0yNlsRBIEK6okDwiUVb_XulmbQoXcCQ0fMAXQU6llk2R7w-jw9gbpjbHwfjRUtw/s320/Thai-Summit-Plex-KORS-small.png" width="320" /></a></div>Cloud has become the preferred deployment option for most categories of enterprise systems. But conventional wisdom is that some systems that require low latency and a high degree of system availability, such as warehouse management systems (WMS) or manufacturing execution systems (MES), are best deployed on-premises.<p></p><p>The argument is that response time over the Internet is never as fast as over a local area network and that such systems cannot tolerate any level of unscheduled downtime inherent in using a cloud application. </p><p>Nevertheless, cloud systems are invading even this category of software. Although still in the minority, there are some vendors providing such low-latency applications as a cloud service. </p><p>One example is <a href="https://www.plex.com/" target="_blank">Plex Systems</a>. And, interestingly, it is not a new example. </p><p>Read the rest of this post on the Avasant website: <a href="https://avasant.com/report/deploying-low-latency-applications-in-the-cloud/">Deploying Low-Latency Applications in the Cloud</a>. </p><div><br /></div>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-3511056.post-40444432105508230622020-08-18T11:08:00.001-07:002020-08-18T11:11:24.014-07:00Why Would Oracle Want TikTok?<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifPVAaP8L-Qf7CgQXEHa2YS_F8fitGA27TBh24OrQvroK6SkebAbN2yf4oCfuux1ZVNWVk3do-RTr1Du3SvobvwPhP_W_46XTFS2bH_-LGPEpnXiDqvom777cfjZdvTYuTGqDZ/s640/TikTok.jpg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img alt="TikTok Logo" border="0" data-original-height="425" data-original-width="640" height="133" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifPVAaP8L-Qf7CgQXEHa2YS_F8fitGA27TBh24OrQvroK6SkebAbN2yf4oCfuux1ZVNWVk3do-RTr1Du3SvobvwPhP_W_46XTFS2bH_-LGPEpnXiDqvom777cfjZdvTYuTGqDZ/w200-h133/TikTok.jpg" width="200" /></a></div>Oracle is reportedly in talks to acquire the certain operations of social video service TikTok. <div><br /><div>I'm hearing through the back channel that the move is not being well received within Oracle itself this morning. <br /><p></p><p><a href="https://www.theverge.com/2020/8/18/21373225/oracle-tiktok-us-business-acquisition-ellison-trump" target="_blank">From the Verge</a>: </p><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><p style="text-align: left;">Oracle has expressed an interest in acquiring TikTok, according to the Financial Times, giving Microsoft a potential competitor in its bid to control the Chinese social video app in the US. Larry Ellison’s enterprise software giant has reportedly held preliminary talks with TikTok’s parent company ByteDance already, working with venture capital firms including General Atlantic and Sequoia Capital, and is “seriously considering” acquiring its business in the US, Canada, Australia, and New Zealand.</p></blockquote><p>So why would Oracle acquire a business that is so far out of its market space? </p><p>I've heard speculations from various quarters. It could be motivated by a desire to leverage TikTok's user data to enhance Oracle's marketing products. It could be motivated by a desire to get into a consumer business. It could be motivated by a desire to hurt Microsoft--something that would fit Ellison's competitive nature. </p><p>There's one more possible motivation I haven't heard mentioned, and that is to get TikTok's huge workload for Oracle Cloud Infrastructure (OCI). Oracle's market share lags far behind Amazon, Microsoft, and even Google's. There is a bit of a chicken-and-egg problem facing Oracle, however. Cloud infrastructure providers need large workloads to realize economies of scale, making them price competitive. But how can Oracle achieve that scale? One way is to buy the workloads. And what bigger workload than a video-sharing service? </p><p>This is likely the reason that it offered a deal to host some of Zoom's workloads on OCI. So, it might also be the primary motivation for Oracle to pitch for TikTok. </p><p>Anyone with me? </p></div></div>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-3511056.post-48455013803278267582020-08-08T11:34:00.003-07:002020-08-08T11:36:43.191-07:00Impact of the Coronavirus Pandemic on IT Budgets in 2020<p>Over at Computer Economics, we just published our annual <a href="https://www.computereconomics.com/page.cfm?name=it-spending-and-staffing-study"><i>IT Spending and Staffing Benchmarks</i></a> study, now in its 31st year (click to download the free executive summary). </p><p>This year, however, there was a bit of a complication: The COVID-19 pandemic hit right in the middle of our survey period. So, in order to measure the impact of the pandemic, we added special questions to our survey and also went back and re-surveyed those who had already responded. We published the results in a special supplemental report: <a href="https://www.computereconomics.com/article.cfm?id=2864"><i>Impact of the Coronavirus Pandemic on IT Budgets in 2020</i></a>. The results are interesting, and we plan to repeat the survey in the coming weeks. </p><p>In addition, Dave Wagner and I gave a free webinar to present a summary of the results of both reports. Click the image below to watch the full replay. </p><p></p><div style="text-align: center;"><a href="https://avasant.com/report/computer-economics-impact-of-the-coronavirus-pandemic-on-it-budgets-in-2020/#webinar-form" style="display: inline; padding: 1em 0px;" target=""><img border="0" data-original-height="891" data-original-width="1468" height="243" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgliYQGvtq9YNpcqfVLpIMAjifR_eNvetWDAqOhgoV99lsTXC26OVW6UBpdkWbZRq8UQJjMQrnnVwSG8JXEu_BbBBlKfb-rF8StPvwLo81sNFhvPDQNkLnyQeq39K9gklWk3PiK/w400-h243/FrankScavoDaveWagnerWebinar.png" width="400" /></a></div><p></p><p> </p>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3511056.post-52744341190464712252019-09-18T10:04:00.003-07:002019-09-18T10:05:10.638-07:00IFS and Acumatica Living Together in the ERP Space<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRK9gYnsGFzn9Kg87q_XYZMBroo6aUXq-20DzG3aDZepLWv0y24O7BmPpUgUk9GKPu7kWDvvcYFM44gWJTxUWUK7WTRf-sf0oxDpcECNXU6GmghnkDqqkVEgfUYP0TzyvjA1MH/s1600/Roskill-and-Roos.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="504" data-original-width="680" height="237" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRK9gYnsGFzn9Kg87q_XYZMBroo6aUXq-20DzG3aDZepLWv0y24O7BmPpUgUk9GKPu7kWDvvcYFM44gWJTxUWUK7WTRf-sf0oxDpcECNXU6GmghnkDqqkVEgfUYP0TzyvjA1MH/s320/Roskill-and-Roos.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Photo Credit: Jon Reed, Diginomica</td></tr>
</tbody></table>
When does the relationship between two tech vendors look like a merger but is not actually a merger?
<br />
<br />
For all intents and purposes, that’s exactly what just happened with two players in the enterprise resource planning (ERP) industry. EQT Partners, a global private equity fund, recently finalized a deal to buy Acumatica. Although EQT already owns another ERP firm, Swedish-based Industrial and Financial Systems AB (IFS), it is not merging them. Rather, the two firms will work closely together, while remaining separate entities under the same EQT holding company. EQT’s Jonas Persson will serve as chairman of both companies, and IFS CEO Darren Roos (pictured above, on the right) will assume a seat on Acumatica’s board.<br />
<br />
IFS may not have the name recognition of SAP, Oracle, or Microsoft, but
at about 10,000 customers worldwide, IFS is much larger than Acumatica.
It counts in its arsenal corporate giants such as Toyota, BMW, Pepsi,
John Deere, and the largest container ship company in the world, Maersk.<br />
<br />
It’s
not that a merger was not on the table. EQT’s acquisition came after
IFS considered buying Acumatica outright, Roos said recently at an
analyst event. After carefully considering the situation, EQT decided
that IFS and Acumatica are different enough that a different strategy
was needed, to keep the two firms separate.<br />
<br />
For its part,
Seattle-based Acumatica has grown to more than 5,200 mostly small and
midsize customers in 11 years. It is known for packaging its products
into industry “editions.” Each edition marries Acumatica’s horizontal
functionality (primarily financials, distribution, and customer
management) with industry-specific modules, such as commerce,
construction, manufacturing, field service, and distribution. Acumatica
sells these editions through a network of value-added resellers (VARs).<br />
<br />
Read the rest of this post on the Strativa blog:<br />
<a href="https://strativa.com/ifs-and-acumatica-living-together-in-the-erp-space/">IFS and Acumatica Living Together in the ERP Space</a><br />
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3511056.post-12167463309491674512019-08-28T13:20:00.000-07:002019-08-28T13:20:20.129-07:00The Use and Misuse of PaaS<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7PnVXPH0-GAg8gFoA9zqhAuQdrFObIDqv6yGPvXmEh_LnRsULAJdxoARu4k2uuawFKS2lNwUEr6V0R6B12NzB6l1h7Gq1r7sUKhU5rziCaDD4mQJpz8u-OjMVJAPsIh4UIxBe/s1600/frank-scavo-paas.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="472" data-original-width="704" height="214" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7PnVXPH0-GAg8gFoA9zqhAuQdrFObIDqv6yGPvXmEh_LnRsULAJdxoARu4k2uuawFKS2lNwUEr6V0R6B12NzB6l1h7Gq1r7sUKhU5rziCaDD4mQJpz8u-OjMVJAPsIh4UIxBe/s320/frank-scavo-paas.jpg" width="320" /></a></div>
One of the key
advantages of modern cloud systems is that they often come with rapid
development platforms that allow the vendor, partners, and even customers to
build extensions and customizations to the system without affecting the
underlying code or architecture of the base system. These are generally known
as Platform as a Service (PaaS).<br />
<br />
Examples include the Salesforce Lightning
(formerly Force.com) platform, the SuiteCloud platform of Oracle’s NetSuite,
Acumatica’s xRP platform, Sage Intacct’s Platform Services, Microsoft’s Power
Platform, and many others. <br />
<br />
However, as with so many good things in life, PaaS can be
used and abused.<br />
<br />
Read the rest of this post on the Strativa blog:<br />
<a href="https://strativa.com/the-use-and-misuse-of-platform-as-a-service/">The Use and Misuse of Platform as a Service </a>Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-3511056.post-41010535450165283292019-07-17T13:51:00.000-07:002019-07-17T13:51:09.217-07:00The Benefits of Business Process Framing<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEqBBlchIRLP8kTZv1AJreJbkcn2_le1AgbcQ3t602vdlljWbdA7AMCRSH8ZP0VlLUZ_EHQhnVBn44mbNaezBZhE6U8JaXJFGNLgk1_CrqL7j-fV15qL4EAHnSfccNHtf-iLNU/s1600/process-framing-poster.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="787" data-original-width="1046" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEqBBlchIRLP8kTZv1AJreJbkcn2_le1AgbcQ3t602vdlljWbdA7AMCRSH8ZP0VlLUZ_EHQhnVBn44mbNaezBZhE6U8JaXJFGNLgk1_CrqL7j-fV15qL4EAHnSfccNHtf-iLNU/s320/process-framing-poster.png" width="320" /></a></div>
In selecting and
implementing a new enterprise system, business leaders have learned the
importance of evaluating business processes. “Let’s not make this an IT
project,” they say. “Let’s really understand our current business and our
vision for the future.” Without a doubt, this is right, and we encourage our
clients to do exactly that. <br />
<br />
However, business leaders often think that this means they
should begin with detailed process mapping of their existing processes.
“Let’s have someone come in and map all our business processes,” they say. <br />
<br />
At first glance, this seems logical. If we want to define
our business requirements, what better way than to map our “as-is” processes?<br /><br />Why is this not a good idea? There are at least three reasons. <br />
<br />
Read the rest of this post on the Strativa blog: <a href="https://strativa.com/the-benefits-of-business-process-framing/">The Benefits of Business Process Framing</a>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-3511056.post-73699786037459044272019-06-28T17:06:00.000-07:002019-06-28T17:07:07.291-07:00Time for a Declaration of Independence from Software Vendors?<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxBBCKcnYZjFJOk2x745mu8nfAxG_OD-6uAsU4S5kULB6wpjNvzTlehsr2kC6QOFVh9KlQDgJUx6vsgu0UxfANkWZqdusXTJr7aZyWtV260GufX0YQ_V4YwxL-WhCoghBysz6D/s1600/minutemen-at-lexingon-and-concord.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="391" data-original-width="291" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxBBCKcnYZjFJOk2x745mu8nfAxG_OD-6uAsU4S5kULB6wpjNvzTlehsr2kC6QOFVh9KlQDgJUx6vsgu0UxfANkWZqdusXTJr7aZyWtV260GufX0YQ_V4YwxL-WhCoghBysz6D/s320/minutemen-at-lexingon-and-concord.png" width="238" /></a>When it comes to enterprise IT, every so often we begin to notice
things that cause us to question our basic assumptions. The latest is
about the role of commercial software.<br />
<br />
The traditional advice for companies is that it is best to
standardize on a commercial software vendor for the core of the
applications portfolio. It might be a major vendor, such as SAP, Oracle,
or Microsoft, or it might be any number of other providers. Custom
software should be the exception, not the rule, whether for unique
industry requirements, or for modifications and extensions to the core
system. The more you can rely on a commercial software vendor, the
better.<br />
<br />
We’ve been giving this guidance for decades, whether for on-premises systems or with cloud-based systems.<br />
<br />
<br />
Nevertheless, some of our clients are starting to rebel against the
conventional wisdom by developing more of their own software in-house.
Moreover, they are not doing it just on an occasional or exception basis
or for niche applications. They are doing it for domains where we
traditionally assumed that commercial software was the natural choice. <br />
<br />
Read the rest of this post on the Strativa blog: <a href="https://strativa.com/declaration-of-independence-from-software-vendors/">Time for a Declaration of Independence from Software Vendors?</a>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-3511056.post-64370049819599035232019-06-19T18:57:00.007-07:002021-08-07T08:27:51.871-07:00What I Learned at Macy's about Enterprise IT<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwtZGAxp-wwtCvXLdzvz8gIovMJgupWlbeoaOb5ndo1LD3QiNJ2zeC56ayWSdyQXqQya-PmDh9AV-9wvUBaBatsej5isBUwicrcJDh7_dX2WHu_jGjNfJO1L7rOtAwpZ-rVPLJ/s1600/Macys-Wiki.jpg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="960" data-original-width="1280" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwtZGAxp-wwtCvXLdzvz8gIovMJgupWlbeoaOb5ndo1LD3QiNJ2zeC56ayWSdyQXqQya-PmDh9AV-9wvUBaBatsej5isBUwicrcJDh7_dX2WHu_jGjNfJO1L7rOtAwpZ-rVPLJ/s320/Macys-Wiki.jpg" width="320" /></a></div>
As incredible as the changes have been in information technology over the decades, what is also fascinating is the ways in which things have not changed. As I am approaching the half-century mark in my career, I thought it would be helpful to look back to understand the lessons learned that still apply today.<br />
<br />
As you can imagine, this will be a much more personal post than usual. And be sure to check out the footnotes, which include interesting but tangential details about work life during that time. <br />
<br />
My career began at R.H. Macy in 1974, at its headquarters and flagship store at Herald Square in Manhattan, made famous in part by the film <i>Miracle on 34th Street.</i> Just as in the movie, the store was directly across the street from Macy’s greatest rival at the time, Gimbel's. And, even in 1974, much of the building looked the same as it did in the 1947 movie.<br />
<h3>
Hired with No Experience</h3>
I did have some programming courses at the University of Pennsylvania, which I took after I realized that my geology major probably meant a career in the oil patch or in mining regions of the world—not places where I particularly cared to live. So, I thought, how about computer programming? As an undergraduate, I had one course in programming at Penn’s Moore School, home of the ENIAC, one of the first digital computers. In that course, I learned some Fortran and ALGOL, both now largely forgotten. The next year, I took a graduate course in IBM assembly language. I also did some Fortran programming for a few months for a professor in environmental science at nearby Drexel University.<br />
<br />
This was the extent of my programming experience by the time my newlywed wife, Dorothy, and I moved to New York City. She took a job as a medical transcriptionist at New York University Hospital<sup>1</sup>, and I started searching the classified ads in the New York Times.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSIzQGN0BouxLwBoZSI13iefkU1KOv1_pknaUwzoSQOAERGi8qHv9t5t27ZQUWgxqnmWWy1u2cVGpsLrkPCWAP6aI7dfnTd9JYs4O4-KVobgZZTQnBETdrywzQ9ofpmSkeasBV/s1600/Macys-Clown.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="338" data-original-width="299" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSIzQGN0BouxLwBoZSI13iefkU1KOv1_pknaUwzoSQOAERGi8qHv9t5t27ZQUWgxqnmWWy1u2cVGpsLrkPCWAP6aI7dfnTd9JYs4O4-KVobgZZTQnBETdrywzQ9ofpmSkeasBV/s320/Macys-Clown.png" width="283" /></a>Macy’s was running an ad for computer programmers. A college degree was a prerequisite, but no programming experience was required. As part of the hiring process, Macy’s administered a test for programming aptitude—mostly for ability to understand symbolic logic. I aced it, and I was hired into a group of about 25 applications and systems programmers.<br />
<br />
Interestingly, Macy’s Data Processing (DP) department (as it was known before MIS or IT became the common term) only hired trainees. Even the department head, Joel Thayer, had started as a trainee. (In addition to his job responsibilities, Mr. Thayer was also the head of the roller-skating clown act in Macy’s annual Thanksgiving Day Parade. I regret that I was invited to join but never did.) <br />
<h3>
Go Talk to the Users</h3>
COBOL and IBM assembly language were the two programming languages in use then at Macy’s. I’d had a little assembler language training but no COBOL. So, Mr. Thayer sat me down at my desk<sup>2</sup> and gave me two COBOL training manuals to study. After a day and a half, I got bored and told him I was ready for an assignment.<br />
<br />
So, he brought me into his office<sup>3</sup> and explained that we were a few months from the holiday season and that he had a quick project for me: Take Macy’s entire credit card account file and print “Holiday Money” coupons for eligible customers. These could be used by account holders like cash in the store, except that any purchases made would simply go on their credit card accounts. The thought was, if you give people something that feels like cash, they might spend more, or at least choose to shop at Macy’s rather than at a competitor’s store.<br />
<br />
It was a pretty straightforward specification<sup>4</sup>, and I thought I could write the code<sup>5</sup> based on Mr. Thayer’s verbal instructions. But first he told me, “Now, put on your sports jacket, and go down and talk to Richard Miles, the VP in the credit department, and be sure this is right.”<br />
<br />
Less than two days on the job as a trainee, and I was going out (by myself!) to talk to a senior executive about his requirements. I’m pretty sure that Mr. Thayer knew it wasn’t necessary to have me do that interview, and, as expected, the meeting was uneventful. But Mr. Thayer was teaching me my first lesson.<br />
<br />
<i><b>Lesson Learned:</b> Our job is not just about technology. It is about understanding the business, and you can only learn business requirements by getting close to the users. Keeping with this principle, every new programmer at Macy’s started with the role of programmer/analyst, not just programmer. Understanding user requirements was part of the job from your first day. Here’s the first way things have not changed.</i><br />
<h3>
Programming without a Computer</h3>
I can’t find evidence of this, but the old timers told me that Macy’s was only the second or third commercial organization to deploy a computer, one built by National Cash Register (NCR) in the early 1950s. Of course, in those days, virtually no one had experience in computer programming, so Macy’s trained its own programmers from the ranks of a department known as “Systems and Procedures.” (More about that department in a moment.)<br />
<br />
At the time I was hired, there were still two or three of those first programmers working at Macy’s, now as DP managers. The most senior one, Abe Horstein, was the original programmer who wrote the code for the accounts receivable system, which managed all of Macy’s credit card operations.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_B4wEaibUpkrZ91SdXHt-IBqbn4Gy7iCEV-rg66afn1MHq7ou9M7GORUinoA-AxaWfkY5vtJAB4CTxN4Wn4ZQtvQywTldybcDINQ_6i4OPuelUiYxXmguFHxPKGqnc5X04fX4/s1600/Bubble-chart.png" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="1091" data-original-width="962" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_B4wEaibUpkrZ91SdXHt-IBqbn4Gy7iCEV-rg66afn1MHq7ou9M7GORUinoA-AxaWfkY5vtJAB4CTxN4Wn4ZQtvQywTldybcDINQ_6i4OPuelUiYxXmguFHxPKGqnc5X04fX4/s320/Bubble-chart.png" width="282" /></a></div>
Although Macy’s rewrote this system in the 1960s in COBOL for the IBM mainframe, Abe was still the go-to guy when we had questions on the program logic. To refresh his memory on particularly complex sections of the code, he would often reach down to the bottom drawer of his desk and pull out a three-ring binder with old dog-eared hand-drawn flow charts, which he called bubble charts, similar to what I’ve drawn nearby<sup>6</sup>.<br />
<br />
During one such session with Abe, he told me a funny story. Macy’s contracted with NCR for that first computer, probably a year or so in advance of its being built. In the meantime, Macy’s wanted to get started on its top priority—computerizing that A/R system. Abe was tapped for the job. He learned to code and began a months-long effort to design and program the new system. The plan was to have Abe fly to California (I believe) to test his program prior to the new computer being shipped to New York.<br />
<br />
Finally, the big day came. The computer was built, and Abe was ready to fly out west. But first, fearing the possibility of a plane crash, Macy’s top management insisted on photographing the hundreds of pages of computer code—but not as a backup. They actually kept the originals and sent Abe with the photocopies!<br />
<br />
Ultimately, Abe got the program running and the new computer was shipped to New York, where it supported Macy’s A/R system<sup>7</sup> By the time I left Macy’s two and a half years later, I was responsible for the nightly processing and maintenance of that system, now rewritten for the IBM 360<sup>8</sup>.<br />
<br />
<i><b>Lesson Learned: </b>Some programmers today think that well-written code is its own documentation. I disagree. Well-written code can explain what the program does, but what is often missing is the “why.” Although program flow charts are usually not needed, there is still the need for documentation at a higher level, especially concerning the business logic. Throughout my career as a developer I always made an effort to document things I thought my successors would want to know. </i><br />
<h3>
Does Macy’s Tell Gimbel’s? </h3>
My first programming assignment was successful. After I had finished, Mr. Thayer told me a funny story. As noted earlier, Gimbel’s department store was still across the street from Macy’s, and the two were rivals. In fact, “Does Macy’s tell Gimbel’s?” was, at the time, a common saying indicating that competitors do not share business secrets with one another.<br />
<br />
Despite this intense rivalry as retailers, Mr. Thayer and his peer at Gimbel’s had somehow managed to enter into a friendly competition whereby each of them would attempt to find vulnerabilities in the store processes of the other.<br />
<br />
To facilitate the competition, Mr. Thayer had applied for and had received a Gimbel’s credit card. As a result, Mr. Thayer had received, in the mail, Gimbel’s equivalent of “Holiday Money,” which he promptly used to purchase some small item at Gimbel’s. He then turned around the next day and returned the item and received his refund in cash. Bingo. If he had made the purchase by credit card, the returns department would have simply applied a credit to his card balance. But Gimbel’s treated Holiday Money as if it were really cash. In effect, he had gotten a cash withdrawal on his Gimbel’s credit card, something that should never have been allowed. Mr. Thayer then went over to visit the Gimbel’s DP manager to let him know about the vulnerability. It was, indeed, a friendly rivalry.<br />
<i><br /><b>Lesson Learned: </b>Take the opportunity whenever possible to learn from your industry peers, even if they are competitors. Of course, no one should share trade secrets with competitors, but we can and should learn from one another in areas such as IT security, technical standards, and open source, where we can all mutually benefit for “the greater good.”</i><br />
<h3>
“I Just Want a Hot Steak”</h3>
Earlier, I mentioned that Macy’s DP department had its roots in a group called the Systems and Procedures department. The word systems here did not refer to computer systems but to the manual systems that ran Macy’s store operations. They spent a lot of time designing forms, filing systems, and procedures. So, when computers became commercially available, this department was the natural group to implement them to automate those procedures.<br />
<br />
Macy’s DP department still had this orientation toward business processes when I joined almost 25 years later. For example, one day Abe told me an interesting story while we were having lunch down in the employee cafeteria. He pointed to employees paying at the cash register. He remarked that a few years earlier he was frustrated that there would typically be a bottleneck in front of the cashier and that, by the time he sat down to eat, his lunch was cold. So, he wrote up a formal suggestion to rebalance the serving lines and cashier lines to remove the bottleneck. Today, we’d call this lean thinking. Abe’s solution didn’t involve computers, but it greatly improved the process by getting employees quickly to their tables after being served.<br />
<br />
Macy’s employee suggestion program included a reward program for suggestions that were accepted and implemented. Abe’s suggestion was soon implemented, but he refused the reward. He said something to the effect of, “It’s my job to improve processes. I don’t want a reward. I just want a hot steak.”<br />
<br />
<i><b>Lesson Learned: </b>Despite all the advances in technology, enterprise IT is still all about thinking in terms of business processes. If you’re going to be successful, you have to be like Abe, who was reengineering business processes even while at lunch, at least 20 years before Michael Hammer coined the word.</i><br />
<h3>
Human Costs Unavoidable</h3>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjP9jb1QKLrwcadEtrOKM-Dd95Ko8XvwBGcxppzycrOQR5MwqjZSMQPk7FF0TO4J542IaoERZUGUmSdCEdoNBevC1vixn5L66poVxuwp0bIIMA47LgUG7EynsZOTz8AZ0o9LXY/s1600/burroughs-calculator.jpg" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" data-original-height="240" data-original-width="305" height="249" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjP9jb1QKLrwcadEtrOKM-Dd95Ko8XvwBGcxppzycrOQR5MwqjZSMQPk7FF0TO4J542IaoERZUGUmSdCEdoNBevC1vixn5L66poVxuwp0bIIMA47LgUG7EynsZOTz8AZ0o9LXY/s320/burroughs-calculator.jpg" width="320" /></a></div>
But process improvement wasn’t always painless. Sometimes it automated people out of their jobs. <br />
For example, when I first started at Macy’s, there was a department of about 20 women who produced daily flash sales reports using large mechanical calculators, as shown nearby. This group sat right next to our DP department.<br />
<br />
One morning as I walked to my desk, I saw that this entire group was gone—all the women and their calculating machines had vanished. I asked Abe what happened. “We wrote a system,” he replied. He didn’t say it in a cold way, but as if to say, it’s too bad but we have no choice.<br />
<br />
The impact of the new system was great. It was much faster and more accurate than human calculators. Instead of tabulating data from paper receipts, data from cash registers could now be collected and fed into the IBM mainframe. This allowed daily sales to be reported more quickly, greatly improving management decision-making. If Macy’s didn’t do it, Gimbel’s surely would and no doubt did so.<br />
<br />
Interestingly, Macy’s was the last place where I saw a human elevator operator. He was a kindly old man, who was still there when I left a year or so later. His job, of course, eventually was automated.<br />
<br />
So, yes, there is a human cost. But as these jobs were being destroyed, new jobs, like mine and the rest of our team’s, were being created. As a result, unemployment today is actually lower than it was at the time Abe automated the flash sales department.<br />
<br />
<i><b>Lesson Learned:</b> Today, robotics, machine learning, and other new technologies continue to automate jobs out of existence. Is there a human cost? Of course there is. Do workers need to be retrained? Yes. But if history is any guide, the labor market will adjust. Color me optimistic. </i><br />
<h3>
Equipped for the Next Chapter</h3>
After two and a half years, I was a pretty good COBOL programmer and passable in IBM assembly language—enough to qualify me for my next job, which involved a move cross-country.<br />
<br />
Remember that vice president whom I interviewed about Holiday Money the first week on the job? He gave me a job recommendation that proved critical. But more importantly, I was equipped with important lessons learned in what it means to be a business analyst, understanding the business through the eyes of the users, and helping them improve business processes, themes that continued through the rest of my career.<div><br /></div><div><b>Update</b>: For the next chapter, see: <a href="https://fscavo.blogspot.com/2021/06/enterprise-it-at-trw-credit-data.html"><i>What I Learned at TRW Credit Data about Enterprise IT. </i></a><br />
<br />
<hr />
<h4>
Footnotes</h4>
<sup>1</sup>My wife’s office was at the end of a long dark hallway that connected it to Bellevue Hospital, founded in 1736, making it the oldest public hospital in the US. At the time (and still now), it included a prison ward for treating inmates and a psychiatric ward. “You are a candidate for Bellevue” remains a family saying of ours to this day.<br />
<br />
<sup>2</sup>The 24 programmer/analysts, like me, sat in two rows of 12 desks each, back to back, with no cubicles, no partitions. We were practicing open offices before they were a thing. <br />
<br />
<sup>3</sup>Unlike the rest of us, Mr. Thayer, as the director of the department, had the only closed-door office. The two managers under him, including my manager, Jack Krigstein, had little cubicles, each at the tail end of each row of programmers (i.e. they were looking at our backs). It was tight quarters. It was also an austere environment. Forget free snacks, we didn't even have free coffee, or any coffee in the office, for that matter. A couple months before I left, the whole department chipped in to buy a coffee maker, but only used it for hot water to make instant coffee. <br />
<br />
<sup>4</sup>There was an interesting wrinkle to the specification. The preprinted forms were designed “two-up,” meaning that as the form passed through the printer, the program needed to print them with two customers side by side. But to take advantage of bulk mailing rates, it would also need to print them in zip code sequence. The way the splitting and bursting machine worked, it would need me to export the necessary data and count the number of customers, then sort the file in zip code sequence and split it exactly in half, then merge the second half side-by-side with the first half so they could be printed two-up. So, it was not a trivial first assignment.<br />
<br />
<sup>5</sup>Program coding back then was all handwritten. Look down those two rows of desks and you wouldn’t see a single desktop computer, not even a dumb terminal. We wrote all our code in pencil, on standard programming forms. If you wrote out a program and then decided to reorganize it, you got out a scissors and scotch tape (literally, a cut-and-paste). We turned in our handwritten forms to keypunchers, who punched them onto 80 column card stock, which we would submit to the computer room for compilation. A few months after I was hired, we got direct access to the card punch machines, which saved us quite a bit of turnaround time for code changes. Source code libraries were just around the corner, but at this time we filed the physical card decks in cabinets, along with the compilation printouts, and the generated object code (also on card stock).<br />
<br />
<sup>6</sup>I have not been able to find an example of Abe’s style of flow-charting anywhere on the Internet. This must have been a style from the very earliest days of programming. IBM later popularized a more complex version with various shapes, each of which had a particular meaning. In my opinion, Abe’s style was simpler and more useful, and I reverted to it from time to time even years later.<br />
<br />
<sup>7</sup>Today, nearly no one would dream of writing a custom A/R system. But this was standard practice back then. When I joined Macy’s in 1974, every single business application in the company was custom-written, even payroll and general ledger. I didn’t encounter my first commercial software package until four years and two jobs later.<br />
<br />
<sup>8</sup>Although the IBM 360 was a tremendous step forward from previous generations of NCR and IBM mainframes, core memory was just 125K. That’s kilobytes, not megabytes. So we were always looking for ways to optimize our code and save a few bytes here or there. A few years earlier, when memory was even more constrained, one programmer had come up with a unique way to reduce memory requirements for a batch program. Instead of including the end-of-run logic as part of the program, he compiled that logic and stored it as executable code in the last record of the input file, which was on tape. When the program got to that record, it would load the record into core memory and branch to it to execute the end-of-run logic. It was a brilliant solution, but it was extremely difficult to maintain. <br />
<h4>
Image Credits:</h4>
1: Macy's storefront today, <a href="https://commons.wikimedia.org/wiki/File:Macy%27s_Department_Store_-_New_York_-_USA_-_panoramio.jpg" target="_blank">Paulo JC Nogueira</a> <br />
2: Roller skating clown, <a href="https://www.flickr.com/photos/diariocriticove/8208603193" target="_blank">Diariocritico de Venezuela</a> <br />
3: Example of bubble chart format, from author's memory. (Not an original of Abe's). <br />
4: Burroughs Adding Machine: <a href="https://www.flickr.com/photos/sampitech/2645040778/" target="_blank">Chris Kennedy.</a> </div>Unknownnoreply@blogger.com5