Employee Published Articles

In recent industry news , networking giant Cisco has announced its exit from the hyperconverged market, leaving many of its Hyperflex customers in a state of uncertainty. The company has recommended that these customers transition to Nutanix, a move that has prompted important questions about the future of hyperconverged infrastructure and the choices facing IT professionals. In this article, we'll delve into Cisco's decision, its implications, and alternatives for customers facing this transition. Cisco Bids Farewell to Hyperconverged The news of Cisco's exit from the hyperconverged market comes as a surprise to many. Cisco's Hyperflex product line had gained some traction in the industry, and its sudden departure raises questions about the viability of the hyperconverged approach. The Nutanix Recommendation Cisco has advised its Hyperflex customers to consider making the switch to Nutanix, another prominent player in the hyperconverged infrastructure space. While Nutanix offers a robust solution, this recommendation prompts a critical question: Do you really want to switch from the control of one vendor who abandoned the market to another? A Cautionary Tale for IT Professionals Cisco's exit from the hyperconverged market serves as a cautionary tale for IT professionals. It highlights the importance of carefully evaluating technology choices and considering the long-term implications of vendor decisions. While hyperconverged infrastructure can offer advantages in terms of simplicity and scalability, Cisco's exit reminds us of the risks associated with relying on a single vendor for such a critical component of your IT infrastructure. HPE's Response: dHCI Hewlett Packard Enterprise (HPE) has been closely monitoring the challenges associated with hyperconverged infrastructure and has responded by introducing disaggregated hyperconverged infrastructure ( dHCI ). This approach offers the benefits of hyperconvergence while avoiding some of the limitations that have become apparent in traditional hyperconverged solutions. A Return to Converged Infrastructure Interestingly, many organizations that once embraced hyperconverged infrastructure have begun to return to more traditional converged infrastructure solutions. They have found that the flexibility and freedom afforded by converged infrastructure, with separate compute, storage, and networking components, allow them to better adapt to evolving business needs. Exploring Alternatives For Cisco Hyperflex customers who are unsure about making the switch to Nutanix, there are alternatives to consider. One option is to revert to Cisco Unified Computing System (UCS) for compute and select an appropriate Alletra model to support the workload. This transition would effectively shift from a hyperconverged model back to a converged one, offering greater flexibility and control. In conclusion, Cisco's exit from the hyperconverged market is a significant development that prompts IT professionals to reconsider their approach to infrastructure. While Nutanix may be a viable option for some, it's essential to evaluate all alternatives and carefully weigh the long-term implications of your choice. As the industry continues to evolve, flexibility and adaptability will remain key considerations in building a resilient IT infrastructure.

In January 2021, SAP announced RISE with SAP. With a little over a year into the RISE offering, let’s look at its impact on the SAP customer base, what customers know, and how they feel about RISE with SAP. For starters, let’s be clear on what RISE with SAP is. RISE with SAP is not a product; it is an offering. RISE with SAP is actually a bundle consisting of SAP S/4HANA Cloud, cloud infrastructure, business process intelligence (from SAP’s Signavio acquisition), technical services for the transition process, minor support services, and some credits for SAP Business Technology Platform (SAP BTP – a rebranding of SAP Cloud Platform), all rolled into a single contract. SAP refers to RISE with SAP as Business Transformation-as-a-Service (BTaaS), something that goes beyond a Software-as-a-Service or Infrastructure-as-a-Service offering, that it’s everything you need to run the intelligent enterprise in a single bundle. Confused yet? Don’t worry; you’re not alone. When SAP announced RISE with SAP in January 2021, it left the SAP community with the same confusion. The echoes of What? Where? Why? How? questions could be heard everywhere, and truthfully even SAP didn’t have all the answers at first. But SAP has made RISE with SAP a priority since its release. Data from an SAP Insider Nov. 2021 survey shows at least a quarter of respondents had no knowledge of RISE’s components.

When evaluating any large ERP project and its go-live strategy, especially an SAP implementation, leaders should be informed there will be some impact on their operations. Since it will happen, it's not an "if," so don't call it a risk. Instead, the right questions to ask are: "how much of an impact will there likely be and where?" And, "what can we do to minimize the impact and duration of the "J" curve before we're back to normal or even realizing improved operations?" This article will address the underappreciated side of implementations, user adoption, which according to ASUG, is the #1 reason implementations succeed or fail. And for the record, user acceptance is not enough. You can accept something you don't like and still be forced to work with it. User adoption goes beyond acceptance; it occurs when users become advocates, even delighted with the new efficiency, manual work reduction, empowerment, and so forth with the new solution. Just like an organization has project workstreams by process areas like Finance or Sales, the Change Management team leads user adoption. In addition to the classic functions of communications and training, a Change Management team should be present in every project of any material size and scope, especially where end-users or customers are involved.  Simply put, if users are engaged and on your side, you can get through most anything! However, if the users aren't engaged, consulted for feedback, equipped, and trained, it's a sign of trouble. Worse, if they are not ready to go through a short transition period where kinks need to get worked out before it gets better, your organization will have significant change management issues to deal with in a short amount of time. Lack of user acceptance (a prerequisite for user adoption) is a recipe for disaster that lands most companies on the front page and sometimes even bleeding on the P&L statement for that quarter. Where do you start with change management? In the beginning, of course. Brand the Project and Build Engagement Companies that like to compete give their "enemy" a name. It could be an internal foe such as complacency or "old ways," or a true competitor in the marketplace you want to take market share from. For example, Apple chose Microsoft as its "enemy" in the desktop wars as a way to rally the troops and unite under a common cause that could take years of battles to play out before declaring victory in the war. Similarly, commanders know there will be injuries and setbacks along the way, so they strategize to minimize those impacts. When well-equipped armies are also armed with high morale, they rarely fall. Also, troops with high morale and a shared mission to achieve can overcome well-equipped armies. See the common thread there? Branding your systems integration project serves several purposes: Creating a simple internal marketing campaign is an overt statement from leadership that this project is not business as usual. Creating enhanced communications and seeking input from business users - raises organizational awareness that the project is a priority. Engaging all levels of the organization in the project's goals and objectives creates mutual ownership and accountability. Too often, systems enhancements are seen as the property of IT. That impression is often reinforced by IT's inability to communicate within a given organization effectively. Outreach and effective communication initiate the process of transferring system ownership from IT to business users. Branding generates excitement and team cohesion. SI projects are a grind – they are rarely executed perfectly to plan. Teams often face times of stress and conflict. Creating some simple artifacts of the project (inexpensive tee-shirts, coffee mugs, trinkets) builds a sense of unity that the organization is unified and operating as a team. Call it what it is, a significant change. The project or digital transformation program has a name, so plan and communicate about the go-live accordingly. Do what you can upfront to imagine the weeks leading up to go-live, the first few days, and the first few weeks after go-live until you've executed all your recurring business processes a few times, including the first month-end close. For example, from the business side, if you are a manufacturer and can produce more products ahead of a go-live period, consider buying enough materials in advance and planning enough labor and storage to make up for an expected dip in productivity. This pre-planning removes the sourcing and manufacturing delay while having ample stock sitting on shelves ready to ship until prior productivity levels are achieved after go-live. Involve and engage your team from the beginning, giving them a sense of input and responsibility for ensuring their concerns get heard. For example, if they do something 200 times a day, the project team should know to address that in the design and performance requirements of the new system. Ensure that they walk through every "happy path" scenario (what happens when everything goes right for the 80% use case) as well as every exception scenario (what shouldn't happen but does happen every so often). John Kotter, one of the leading scholar-practitioners in the space of managing change, said, "The true purpose of Change Management is not just to communicate, train and support end-users. Indeed, any process of Change Management does all those things. However, a truly effective process of Change Management should have as its goal the transfer of system or process ownership to business end-users. Only through comprehensive user engagement is this goal achievable." Next, and I can't stress this enough, involve them as champions in the project, from the initial planning and blueprint, through development, testing, and cutover preparation if at all possible. Suppose you emulate what marketing focus groups do, giving unfiltered feedback on a product before getting greenlighted to go to development and asking them to do the same on your proposed solution. In that case, you'll filter out the vast majority of issues lying in wait for the first day of go-live. The creation of an organized network of superusers is an invaluable tool for long-term project success. A fundamental weakness of many ERP integrations is the failure to engage business users early in the project lifecycle. Business users have a vested interest in the proper configuration of any new system. At launch, system functionality ownership is transferred to business users and will affect commercial success or failure. In many projects, assumptions about use cases and business needs are incorrect and directly affect the business's perception of the integration team. By fully integrating select business users in the project and creating power users within the business, course correction on functionality or configuration can be quickly achieved. Superusers serve as the first line of defense in organizational communications. No project is perfectly executed. Large-scale transformations face periods of conflict and indecision. When frustration peaks, corporate rumors can have a destructive effect on team morale and leadership's confidence. Influential business users integrated into the team can take leadership in quelling misinformation and provide organizational leadership with a credible perspective on the challenges the team is facing. During training, superusers are effective class proctors for instructors. Business users who fully understand process design can effectively translate the theoretical to the practical within their given organization. At go-live, they should serve as the first line of support so that when end-users have trouble, they will be supported from the office or cube next door instead of calling a support desk. Listen and Give Them What They Need Of course, give them proper training, including in-person training as needed. Videos. Job aids. Visual reminders and signs. Stickers. They will dedicated time away from their day job to complete project activities and training. Give them a sandbox or training system and tools to practice their new and updated processes and transactions. Communicate and remind them regularly of the upcoming change. Then also accept, no matter how much you've prepared and communicated, there will be plenty of reasons why productivity will be down for the first few weeks as they get used to the new ways of working. They will have to adjust to a new pace, processes, tools, terminology, and even people they need to interact with daily. In any significant go-live, where technology and process changes become real for the first time, mistakes will be made. Orders will be delayed. People will be working more slowly than before and with less confidence. They will probably need refresher training or a job aid. Employees will often get frustrated because they aren't instantly proficient with the new processes overnight. Their excellence with the previous process and technologies was a source of pride (and job satisfaction). So, as a leader, what can you do to turn this mountain, whether real or imagined, back into a molehill in your company's SAP journey? Change is difficult. People are hard-wired to resist and challenge the uncomfortable. While every change generates a dip in performance of some duration, a well-executed change management process can minimize business disruption.

Business continuity addresses the ability for an organization to adjust and survive a disruption to the business, whether it's organizational, safety, environmental, or technology lapse induced. In the case of the technology aspect of protecting our business' ability to operate and recover from issues, we call that backup/recovery at the local level and disaster recovery when discussing recovery processes, often including geographic considerations to accommodate the large-scale problems like natural disasters. A practical, logical framework for planning backup/recovery (and in many areas) is the concept of layers and building blocks. When mapping recoverability needs (RTO, RPO) to the types of data you have and their form, does your process backup each building block and know how they connect? Next, assess your processes, people, and technology platform's ability to deliver the required level of recovery. Then implement backup solutions that address: Company or industry/regulatory-driven data retention and recoverability requirements Service class or tiering system by system or data object Network capabilities and hardware (e.g., LAN, WAN, VPN) across your enterprise's data centers and DR site(s) Virtualization and management software and VM's (usually VMware or Hyper-V) Tools and management information (utilities, certificates, admin account vaults, encryption keys, licenses, vendor support contracts, account numbers, and contact information) Containers (e.g., Kubernetes) Data that resides on "bare metal" server infrastructure like switches, firewalls, specialty server appliances, and virtual tape libraries Operating system images (and dependencies like the local boot and swap/paging spaces) Data resident on filesystems (e.g., transaction/interface files, documents, configuration files, applications; system, application logs, etc.) Database and its related transaction/archive logs System-to-system consistency and restorability Single points of failure (SPOF) in your backup/recovery and DR infrastructure People (and partners) with knowledge, access, and documentation to act on an issue IT disaster recovery requirements Regular disaster recovery testing (at least once per year) Business process resiliency & recovery to ensure overall business continuity Is the Proof In Your Backup/Recovery Pudding? The best proof you have of an effective backup solution is to demonstrate it by exercising your recovery processes and technologies regularly. Common ways to accomplish that goal are system clones, database copies, cloning, and moving VM's. These processes are often used to copy production databases to a QA or Sandbox database, so developers have production-level data quality and volumes to test with. If you haven't had a Backup/Recovery Assessment completed in a while, consider getting a fresh one done using current guidelines and asset inventory since it will have inevitably changed in most cases. Special Mention on Protecting Against Ransomware You should also periodically test recovering sets of individual test files to a point in time based on how often you do file-level backups, how many versions you keep, and how long a full retention timeframe represents. Note that your backup policies and thus your recoverability may (and probably should) vary by SLA tier, e.g., production vs. sandboxes. For example, ransomware attacks were reported to be up 148% in 2021 compared to 2020. They often target shared drives like file servers and shared drives on Office365, encrypting your files and making them unusable. At that point, you hope you have a ransomware protection system in place (ask if you're interested) and can recover all of the files with minimal loss (is <12-24 hours sufficient?). You might hire a cybersecurity firm to see if they can find a way to resolve it. Or, failing those and dealing with a crippled business for 1-2 weeks on average, pay millions of dollars in ransom to get access restored. Studies show that organizations that pay the ransom are also >50% likely to be hit again. Cybersecurity is a modern-day threat that will only grow. While the tools and solutions to protect against such attacks are improving, nothing beats having a sound and proven backup/recovery solution to give you options, minimize the damage, and resume operations as quickly and efficiently as possible. Trust But Verify With a Game Still feeling ambitious and want to take it to the next level? Conduct a "war games" simulation where the lead administrator has been captured (or off on their honeymoon again). The others must prove they can execute a series of tasks to continue supporting the business. Execute the DR test plan and document lessons learned, noting new hosts, passwords, technologies, etc., that might have been introduced (or upgraded or replaced) since the last DR test. In this way, your organization will quickly confirm, layer by layer, process by process, object by object, how well the backup/recovery processes and enabling technologies meet the organization's DR requirements. Conclusion By remaining vigilant through planning, regular testing, and spot-checking your operational processes from a DR mindset when issues occur, your team will be confident, and your backup/recovery capability will continue to be there when a disaster inevitably strikes.

IBM was onto something in the ’90s when they saw the shift needed in the world. Everything would need a lot more integration between client/server technologies -- and professionals to deliver the services required to make that integration work. Lou Gerstner saw what the customer of his customer needed: integrated systems and supported their buying needs via e-commerce. The IBM Global Services division was born and became an industry-leading services giant for IBM, ushering in a new era of capabilities and mindset. I know because I was there. SAP would later use the same concept of “your customer’s customer” when pitching e-commerce solutions in the 2000s, and now with digital transformation. And you know what? It’s a solid concept to teach business and IT staff to prepare for your digital transformation journey. An essential ingredient to this journey is what is called Customer Performance Indicators, or CPIs. Imagine you are a Systems Analyst in the IT team. Your “customer” is the Business Analyst who is gathering business requirements for the new project. To level up your business and IT game, consider who the Business Analyst’s customer is. Is it their Director or VP? No. In the most fundamental sense, the business has deputized the business analyst to deliver results for those who pay for your products or services. So, just as you work towards internal metrics on which you’re measured, often called Key Performance Indicators or KPIs, your end customer also has performance indicators, CPIs, that they measure your organization with. The exciting thing about CPIs and digital transformation is this – their key metrics often don’t resemble your KPIs at all! How can that be? Let’s take an example. Apple wants to sell more iPhones. Apple rewards its employees on hitting their internal metrics, those KPIs, for selling more iPhones, keeping optimum inventory levels (which could be high or low depending on the item), reducing costs, and so on. What do the metrics looking like on the customer side? Well, beyond the one iPhone they were interested in buying, they don’t care how many iPhones Apple sells. They don’t care what “optimum” inventory levels are, just that Apple or a retailer somehow had the one they wanted in stock. They don’t care about how many issues were solved for millions of users worldwide across every possible component or service for Apple’s products.  They don’t care whether the support person has one start-of-the-art AI-powered problem-solving application or has to quietly navigate 11 disjointed, unintegrated applications across multiple screens to manually and mentally patch data together into useful information and eventually arrive at the desired outcome (as I learned about one telecom carrier, no joke). They only care about getting their problem solved with a minimal wait before talking to a knowledgeable support person who will solve it on the first call or chat 99% of the time. Instead, digital transformation begins with people. It starts with the customer and their experience when interacting with your organization and ripples to the employees, partners, and contractors who make, sell, transport, and support your product or service. From this vantage point, the customer has their metrics on how good a company you are. They want their desired iPhone in stock. They want their question or problem solved on the first call to technical support, not bounced around three times and hung up on because that helps internal call center staff maintain their KPI for fast call closure rates. They don’t care if you have different systems for tracking packages, just that it looks like one easy-to-use system that gives them instant, accurate information on their schedule, day or night. Consider this astounding finding by SAP Technology & Innovation Overview and Outlook: “…The companies that are most successful in overcoming these challenges and surpassing their peers are the ones that understand how to consistently deliver exceptional experiences. In fact, organizations that lead in customer experience outperformed laggards on the S&P 500 Index by nearly 80% .” Where KPIs are internally focused, CPIs are customer/user experience focused. These metrics determine if they will convert to a customer after browsing your app or website and finding the information they want -- within a few clicks, each of which took no more than 3 seconds apiece. Their purchase experience will determine whether they come back for follow-up sales. Their overall experience determines if they will happily promote your product to their friends, family, and co-workers and leave good reviews on social media platforms. To the CEO, these experiential outcomes translate views into sales, sales into repeat sales, and customer satisfaction into customer promotion. And there’s nothing more powerful than customers promoting you on your behalf. Sales, repeat sales, excellent service, 5-star reviews, and a strong net promoter score are just a few of the ways your organization will know its digital transformation journey is working. And it starts with leadership deciding that digital transformation is a priority and engaging their team and their partners about what it means to their customers and their organization. Announce you are going to do it. Get started with CPIs and re-evaluating if your KPIs drive the behavior and outcomes you want from the viewpoint of the CPIs. If they don’t, dare to change or eliminate them and create ones. Change your compensation plans. Make your new CPIs and KPIs known to all, and have a way to track them transparently, whether it’s with reports or analytics and feeding them live into a dashboard on your intranet or in an app. Think about an instance when you provided feedback to an organization and never saw a response or change in behavior. Now, think about a time when you saw an organization ask for your feedback, responded quickly, earnestly, and enthusiastically, and took action to resolve the matter to your satisfaction. It’s one thing to see a standard form available for you to leave a comment in, and somehow you know it’s just going to go into a black hole. It’s quite another experience to see and feel one or more people-driven and empowered to recognize a problem, your problem (or request), and see them take action like their heart was in it, that it’s the new way of life(work)…or at least that their job depended on it. In conclusion, in the past organizations have focused on KPIs. And it got them mixed results. But the organizations that embrace digital transformation and add the power of CPIs to their vision, vocabulary, and daily life to transform their customer experience, alongside their refreshed KPIs, will see surprising results. Not only will you build a strong foundation for growth, but you will see new levels of success and sustained customer engagement for whatever comes next in your journey.

Knock knock. Who's there? IT's business requirements. IT who? IT has business requirements too! If your first reaction to the above joke was "IT is separate from the business," or "IT gets its requirements from the business but doesn't have its own,” then this article is definitely for you. If you agreed that IT has business requirements, read on for additional ways to improve receptiveness and value to conveying and meeting IT's business requirements. Addressing the Counterproductive Gap in Mindset We Created Through Language The business and technology markets like controversy and uses “us versus them” to make points about how things are and should be. We've had a similar "call to arms" for several years now about how we need better business and IT alignment. However, despite all the ways IT serves the business, which it should, I still consistently see and hear the perception that IT has no voice and no say in determining "business strategy" or "business requirements." Suppose IT is part of the business, as you say it is. How can IT not also have requirements that should be given the same consideration, evaluation (collectively "airtime" in the C-suite), and funding as business requirements from the lines of business or traditional business stakeholders? Case in point. A CIO is led to believe that while IT is part of the business, his requests or even requirements are discriminated against and have lower stature and importance than requests or needs from his business/functional counterpart. In one case, he may recommend they keep applications and hardware under support. Or keep software maintained to fairly current levels. Why would he specify these "business" requirements? Because he is managing risk if something breaks and knows that the more current his applications are and under active support contracts his hardware is, the more likely he's going to get timely and quality support and problem resolution from his staff and vendors. Why else would a CIO have business requirements? By having good IT hygiene and keeping applications, databases, systems, and infrastructure up to date, his IT organization is better prepared to respond to the business' request to try something out or implement a project. Unfortunately, suppose our CIO's requirements are most often downgraded to a request and repeatedly denied. In that case, it's that much more likely that when the business wants to execute a project or roll out an improvement to their business for their customers or employees, IT has a much higher risk of having to say no. It escalates quickly, as characterized by these quotes below. - “Sure, we just had some layoffs, but as long as you can get funding for some contractors, we can get started right away.” - “I'm not saying no, but we have to take care of these 1-3 minor projects first, then we can get to your project.” - “You're going to have to wait for 3-6 months for us to take care of our other needs first, assuming we get started right away. Did you include a few hundred grand for IT in your project budget? Oh, and we'll need your business team for an extending period of testing too.” - “Can't do that. We'd need to develop more precious capital funding and OpEx approval to pay for all of this. And we'll need 9-12 months. Only then can you, the business, get to work on improving the business." The Challenge to Be Overcome by the Business -- and the CIO The challenge is part cultural and part messaging. When the CIO states his requirements to do IT projects, such as application and/or infrastructure upgrades to stay current, there may be two common challenges: If "the business" counterparts didn't ask for it, they often don't think it provides any value. If the CIO can't equate or otherwise convey the value of doing said upgrade or maintenance project, his business counterparts will likely resist participating in required testing activities. So how does the CIO overcome this common challenge? First, get on the same page IT has needs just like the business. Suppose the business doesn't consistently evolve its business process to adapt to the marketplace, create new products and services, or continuously respond to customer demand for how they want to be engaged. In that case, it's virtually certain the business will begin to lose mindshare, wallet share, and market share because the business' requirements won't be met. Likewise, if the CIO can't have his needs met, the risk is absolutely 100% certain that: Software support and ability to work with it erodes year over year, sometimes even faster. 2. Your team and partners' ability to support aging software diminishes over time. 3. Software support will end. Remember, your organization probably literally has hundreds or thousands of applications, middleware, database platforms, and operating systems that all have a support lifespan of their own. 4. Hardware will go out of support. It will go from hard to get service or replacement parts to be much more expensive to get them, and eventually, the CIO won't be able to get them at all. 5. IT's ability to respond and enable and support the next project the business brings to them escalates quickly from "sure, let's get started" to "we can do it, but need to take care of this too" to "hold up, wait, we have to take care of these needs first before we start on your project." Second, create a way to talk about the impact of technical debt on business agility and risk Use recent examples, both for positive and negative reinforcement. Show where, because IT was up to date and current, IT responded quickly with the business to achieve fast payback and maximum ROI on an initiative or project. Likewise, have an example ready where IT couldn't respond without severe delays, cost, or risk – or at all to the business's current need. If your organization is assessing technical debt regularly, say at least annually, with a technology review including technical debt assessment and roadmap to address those debts, you'll have a good idea about your level of readiness to support business needs. You might come up with a scorecard that factors in elements such as: - Risk : the likelihood of an unfavorable event caused by IT's inability to respond to a business need - Schedule: impact estimated for a delay, measured in weeks or months - Cost : Estimated cost of delay to satisfy prerequisites before a business need can begin being met (could be as small as a few software licenses, some labor, to short projects, or full-on serious capital investments or transformative programs) - Agility : estimated or known hard costs if legal, regulatory, security, contractual, or service-related fees are triggered due to an inability to implement the business' needs in a required timeframe We could add other factors in the mix, such as the difference between being to satisfy an IT need for a given processor technology with existing staff, all the way out to pay premium rates for SME's to deal with outdated and unsupported systems, processes, and technologies. But I think the above elements will give you the rough order of magnitude of the risk, impact, and cost of downplaying IT's requirements as somehow separate from what you usually consider "business requirements" that come from the line of business or functional leadership stakeholders. Conclusion In closing, I pose the following question to you. Do you consider IT part of the business? Consider this: if you've ever been successful because of what IT enabled the business to do, or likewise, disappointed by IT's inability to respond to the business' needs, then IT is absolutely part of the business. Consequently, IT's drivers and requirements need to be recognized, given the same airtime and funding consideration as the requirements from the rest of the business. They are all "business requirements." Do your organization a favor and don't separate the two anymore. Don't let the sometimes-intangible value of IT's business requirements deter you. If needed, assign business-friendly value indicators like risk, schedule, cost, and agility to IT's needs to quantify the value in satisfying IT's business requirements, both now AND later.

The most critical part of a S/4HANA move is convincing your organization to take the journey. This can be accomplished by building a business case on why the move is necessary and valuable to your organization. Unlike the IT days of old, saying a piece of software is out of date or out of support isn't justification enough to upgrade. The line between IT and business is so blurred and intertwined that IT supports business drivers. Therefore, the justification for an upgrade must include business values as well. ROIs from both IT and business. Time and cost savings from both. Value from both. Thankfully, SAP has invested a lot of time and effort over the last few years to help customers build these cases. SAP took an in-depth look at its broad and deep pools of customers to collect an unprecedented amount of data. They then created various tools leveraging this data to guide customers, which we will look at in this series of articles. Each post will highlight one tool I feel has significant value to SAP customers in their S/4HANA journey. This series will not be a comprehensive list of all available tools. So if you're interested in others not covered over this series, feel free to reach out. Today we will cover SAP's Business Scenario Recommendations. This tool is built on Spotlight by SAP. First, it's essential to understand this Spotlight platform. Spotlight was started in 2019 by a few SAP employees as a platform to leverage a customer's actual data to get immediate insight into performances and efficiencies of business processes. This was unique for SAP because previously, their tools were benchmarks from an average of SAP customers across industries, sizes, etc. Now SAP and customers have the power of self-help tools to immediately yield results about how they leverage SAP. SAP Business Scenario Recommendations on Spotlight will provide tailor-made recommendations based on data extracted from your SAP system. The results will help business decision-makers in your organization understand the value of moving your current SAP ERP to S/4HANA. Before we can jump into this tool, let's take a moment and review the pre-requisites. Must be ECC6.0. All EHP versions included. ST-A/PI Version 01S or higher hall be installed on your ERP Authorization objects SM_PBM_DET and S_DEVELOP must be added to the user who executes the report. Must be run in SAP ECC Production environment only. No PRD system copies or other systems may be used. So what is looked at? What do you get? There are five lines of business included in the analysis: Finance Sales Supply Chain Sourcing and Procurement Manufacturing O  ther processes like HR, etc. are not included in SAP Business Scenario Recommendations. Process Overview