With so much hype in the market about Robotic Process Automation (RPA) and the various vendors all rebranding their existing software to RPA, customers are confused by the all the conflicting information and range of functionality. Blue Prism brings a number of experts together to discuss what is going on in the marketplace and the most recent research that has been conducted of the early adopters in this space.
Join us as Sarah Burnett, VP and global lead for automation research at the analyst firm Everest Group, shares her analysis of the automation market, the technology adoption trends, and the outlook for the future. She is followed by London School of Economics Professor Leslie Willcocks and Dr. Mary Lacity from University of Missouri who have studied 14 early adopters of RPA. The results of that research have culminated in their book “Service Automation: Robots and The Future of Work.”
If you’re planning an SAP HANA implementation in the near future, you’re probably on a fierce hunt for guidance.
That’s because despite HANA’s ability to analyze massive amounts of data in real-time, HANA adoption rates have so far been on the low side, although they doappear to be rising as its functionality expands into a major platform for enterprise applications and word about its success spreads. Still, the dearth of real-life experience from which to learn may leave early adopters feeling like they’re making an SAP HANA implementation journey in the dark.
Spend time deciding whether you want on-premises, hybrid or cloud versions of HANA. Maintaining an in-house database infrastructure has always been an expensive undertaking, due to the cost and overhead involved. CIOs must decide if the future direction of their company requires them to partially or fully get rid of their in-house database infrastructure and partially or completely move to cloud. The decision on whether the cost associated with the HANA database is justified may take longer for companies that have already heavily invested in in-house infrastructure. However, undertaking a cost-benefit analysis greatly helps in this decision-making process. Often companies only migrate their old and slow databases to SAP HANA to speed up transactions processing, but leave the applications side as it is or do it later on to take advantage of S/4HANA Enterprise Management offerings.
SAP has positioned the HANA portfolio into two distinct categories:
Technical. This is the powerfully fast database processing side of HANA.
Functional. This is the application side, positioned as S/4HANA Enterprise Management. It’s on the Enterprise Management side of HANA, where there are ongoing innovations and simplifications in business processes taking place. These are released every quarter.
Companies may choose only the technical upgrade by choosing HANA database and leave the functional side for implementation later on, or they may do both at once. However, it is not possible to implement Enterprise Management without first implementing the HANA database.
Address hardware sizing by calling on the experts. HANA’s simpler database, faster CPUs and flexible scaling requires CIOs to diligently conduct hardware sizing when it comes to HANA, since these are an altogether different ballgame than traditional databases, and any misstep could lead to underestimating or overestimating the required hardware. To make the most-informed decision, CIOs should engage multiple SAP HANA-certified vendors and then compare the results and reports of each vendor. If most vendors suggest a similar database size, then it is better to go for the higher estimation of database size. If there’s a significant deviation in hardware sizing estimates from one vendor to another, then CIOs should ask each vendor to provide references to similar sizing projects that they’ve undertaken or get help from SAP to validate the vendor-suggested database size.
Tap into any available HANA knowledge and experience. At this time, there aren’t too many reference clients and industry referrals that CIOs can consult to see how well others have done and the challenges they faced. Being a newer technology that has not been adopted among a lot of enterprises, even SAP consultants engaged in HANA implementation do not have a depth and breadth of experience. Fortunately, SAP helps with its early adopter program, known asSAP Ramp-Up. In this program, SAP engages subject matter experts who then engage with early adopters on a regular basis throughout the duration of SAP HANA implementation to guide and advise on all technical and functional aspects of HANA. SAP also incrementally shares technical guides, user manuals, presentations, roadmaps, accelerators and other assets to enable the client to effectively and successfully implement HANA.
Access SAP Activate. For companies opting for HANA’s Enterprise Management, the S/4HANA deployment methodology SAP Activate ensures expedited and guided S/4HANA Enterprise Management implementation. SAP Activate leverages best practices, guided configuration and proven implementation methodology to ensure a project’s success. SAP Activate eliminates the traditional way of creating an SAP Business Blueprint document that maps current business processes with SAP Best Practices business processes and then conducts a gap analysis — SAP Activate gets straight to the gap analysis. CIOs must be aware that it is still too early to evaluate if SAP Activate will ensure that all important business processes are captured, given that not all SAP Best Practices are currently available in HANA. However, SAP does keep on adding and building up the Best Practices library. So can CIOs rely only on the library as it gets fully built out? Not likely. An approach that seems to work well so far is to use traditional business blueprinting, but also create a variant or additional document by using SAP Activate.
Create an implementation roadmap and stick to it. SAP is continuously rolling out newer functionality and innovations with each quarterly release of SAP S/4HANA Enterprise Management, which can evoke an intense case of FOMO (fear of missing out). But it is critical that CIOs do not let new offerings and features derail the ongoing SAP project. In other words, don’t go back two-steps on an already-agreed upon solution just to take advantage of newer innovations, or the result will quickly become scope creep, skyrocketing project costs and timeline slippages. CIOs should put a hard-stop on adopting S/4HANA innovations until the initial SAP HANA implementation is complete. Later, after SAP HANA implementation has successfully gone live and business processes have matured, CIOs can embark on “continuous-improvements” projects to implement latest S/4HANA Enterprise Management innovations available at that time.
CIOs should be seen as enablers and leaders of change in their business.
CIOs should be seen as enablers and leaders of change in their business. In this buyer’s guide, Computer Weekly looks at how the age of the customer requires IT leaders to
focus on both the business technology and IT agendas; why IT leaders need to use blogging and social media to raise their profile and build influence in their organisations; and how IT leaders can roll out projects ever more quickly without running unacceptable risks.
In this 14-page buyer’s guide, Computer Weekly explores:
- Ways of acquiring new technology management skills
- Lessons and literature for CIOs
- How to role out IT projects faster, without running unacceptable risks
- Case Study: How Atkins ramps up IT speed
Download the guide from: Computerweekly-Acquire new skills for technology management
Today’s CIO faces a broad spectrum of challenges that require business acumen, tech savvy, and strong leadership skills. It’s a tricky balancing act, but knowing about the pitfalls can help.
CIOs run highly technical disciplines and usually come from technical backgrounds. Their strength is in knowing the details of IT work. This gains them respect in the eyes of their staff and enables them to discuss the details of projects. Nevertheless, IT management responsibilities have changed substantially over the past few years. As more IT processes become automated, CIOs must become more business-savvy. CIOs also need strong people, as well as good communication and other soft skills. In this new world, CIOs must embrace new roles. Here are 10 mistakes that can trip up the CIO.
1: Practicing heads-down management
Technical people are task-oriented. They have a natural tendency to get completely immersed in technical problem solving. There is no room for heads-down management in CIOs — yet many continue to focus on the technical aspects of projects, forgetting about the people and the politics that can completely disrupt work.
2: Staying technical
Great CIOs resist the temptation to get into the technical details of IT projects. They understand that it is their job to ensure that the politics and business environment are optimal for projects. They focus on running the necessary interference for their staff to make conditions for success optimal.
3: Not checking project status
It can be difficult for CIOs to get out of their office and onto the “IT floor.” I remember one CIO I worked for as a young staffer. He thought our project was meeting deadline, and the project manager was telling him so, but the project wasn’t close. This project ultimately failed — but it might have succeeded if the CIO had done enough “management by walking around.”
4: Forgetting to praise
IT’ers (and their leaders) are committed to what they do. For most, it is enough to know that a job is well done. Still, everyone appreciates a little praise or recognition. Many CIOs don’t give it often enough.
5: Not communicating clearly about projects
One of the hallmarks of great communicators is that they make an effort to know their audience. They then find ways to communicate by using familiar terms. Coming from technical disciplines that use jargon, many CIOs must acquire this skill.
6: Not knowing the business
Many IT’ers go through their entire careers without ever working in the end business. Consequently, they have to learn the business on their own to make sure that their efforts are aligned with what the business needs. CIOs know this, but some fail to hone their own business skills — which is critical for building credibility with other executives in the organization.
7: Forgetting to forge key relationships
Relationship building with other executives and business influencers in the company is one of the most important things a CIO can do. It establishes a cooperative foundation for IT initiatives and improves the odds of project success.
8: Not being objective in IT platform selection
There is plenty of risk in IT projects. This makes it easy for CIOs and other IT decision makers to fall back on vendors and platforms they already know, even though they might not be the best solutions for the projects they’re working on. Maintaining objectivity when evaluating technology alternatives helps CIOs keep their options open and approach projects creatively.
9: Failing to learn staff capabilities and limitations
Some IT’ers are experts in specific areas of IT, some are great with end business users, and some are journeymen who can succeed in numerous project roles. CIOs are ahead of the game when they get to know their staff members’ individual strengths and weaknesses. CIOs should be facilitating IT training to shore up any staff shortcomings. And they should know which staffers are their go-to players and rising stars.
When projects go wrong, it’s tempting to step in and start running them yourself, especially if you’re in a smaller shop. But when CIOs do this, they neglect other projects and areas of IT that require their attention. A better strategy is to meet with project managers and help them get the project on track. As a last resort, you might need to replace a project manager — but it should be with someone else who can take the project — not you!
What mistakes have you made (or seen other CIOs make) that created problems for IT and the business? Share your experiences with us.
IT Standard for Business (or IT Standard in short) has been developed to support decision makers both in business and IT to have a holistic picture of how IT should be managed in order to provide maximum value for business. Since the business needs should be the main driver in IT management, the emphasis in the IT Standard is on the cooperation between business and IT.
IT Standard for Business differs from many other IT standards and frameworks because it is simple and written in everyday language. This makes it useful for everyone who wants to understand how IT functions should be governed in an organization. The basic framework illustration, called the grid, gives an overview of the five principle elements of IT management which are the following:
- Enterprise Development turns business development initiatives into operational actions in IT.
- Strategy and Governance defines how IT operates and creates value for the business.
- Sourcing and Supplier Management ensures that the company has the services that best fit its business purposes.
- Project and Development Management is essential for organizations to improve and create new solutions to succeed in competitive environments.
- Service Management offers business-aligned services that ensure efficient and uninterrupted business operations.
Read the e-book at: IT Standard for Business – a Model for Business driven IT Management
More information at: https://www.ictstandard.org/
Organisations struggling with bimodal IT projects should adopt a more outcome-centered approach to project management, according to Gartner. This will help them manage the different requirements of “slow” (Mode 1) and “fast” (Mode 2) IT most effectively.
“Enterprise project management organisation (PMO) and application management leaders are struggling to adapt governance processes to handle new, agile Mode 2 efforts that don’t conform to traditional project management structures,” said Donna Fitzgerald, research vice president at Gartner. “A focus on business outcome and value will bridge the gap between Mode 1 and Mode 2 projects.”
Gartner has identified three best practices to enable PMOs to better manage any type of IT project or programme within the portfolio:
Use a Simple Approach to Determine Which Mode Makes Sense for a Project
Determining what Mode to use on a project often has more to do with company culture than anything else.
“While Mode 2 can theoretically be applied to any new project, Gartner recommends a simple construct: consider Mode 1 for systems of record and Mode 2 for systems of differentiation and systems of innovation,” said Fitzgerald.
A system of record is a core system that an organisation uses to run its business, such as finance applications or email provision. While a system of record is vital to the operations of the company, it provides no competitive advantage. Systems of record are classically Mode 1. These projects tend to be more knowable both in clear outcomes and clear approaches to achieving these outcomes, which ultimately amounts to doing the process as well as any competitor. Once this is achieved, there is little incentive to improve further or change the process unless conditions or regulations change.
Systems of differentiation are generally Mode 2 projects, because their value resides in providing capabilities that competitors don’t have. Since the nature of competition is that competitors will copy successful innovations, these capabilities need to constantly improve. The project will likely have a long-term goal that is achieved through several iterative steps that build on one another as success is demonstrated. The exploratory nature of Mode 2 projects is important to their long-term success.
A system of innovation is essentially an experiment. It needs a Mode 2 approach because it is a brand-new idea and there is no established way to plan the details of what will be done.
Define the Intended Business Outcome as the Measure of Project Success
Part of the problem with determining how to measure the value of a Mode 2 project lies in the way we currently measure Mode 1 projects. With a typical Mode 1 project, for example, the sales organisation might submit a request and a business case for implementing a customer relationship management system, with a stated benefit of ultimately delivering increased revenue. If the business case were approved, IT would work with the sales team to establish exactly what aspects of the vendor-provided system offered the core critical capabilities, to ensure the system was configured correctly.
Mode 2 projects, however, are explorative and may not have an obvious list of capabilities by which to define their success from the outset. Instead, Gartner recommends identifying a specific business outcome, such as, “Improve lead conversion by X percent based on better segmentation of marketing campaigns,” and agreeing on this while building the business case — all before the project starts. “This scenario works well across both Modes of projects because the outcome defines the scope, and fulfillment of the scope determines completion, rather than just depending on completing a list of requirements,” said Fitzgerald.
Clearly Separate Portfolio and Project Governance for Easier Bimodal Governance
The final area where many PMOs struggle is how to ensure that they maintain a consistent approach toward governing the project once it has begun. “Place responsibility for the project with the people who can practically make things happen,” said Fitzgerald. “Place responsibility for the investment portfolio with the people who have the authority to make decisions across the entire portfolio.”
“Regardless of the Mode, the PMO supports governance through reporting on progress toward successful delivery,” she said. “This criterion remains the same whether the project is replacing a core financial system of record, or building a mobile app that enables consumers to purchase goods from the company. It ensures a consistent approach across Mode 1 and Mode 2 projects.”