Digital Execution Guide
User Manual: Pdf
Open the PDF directly: View PDF 
.
Page Count: 30
| Download | |
| Open PDF In Browser | View PDF |
Your Starter Guide to Digital Execution Customer success is one of the key pillars of Mendix. We know that implementing a digital strategy is more than just buying a technology platform. From our experience with more than 500 different customers spread over different industries, we have seen many customers be incredibly successful in their first years of implementing a digital strategy, and others get stuck within their first few apps. Over time, we have used this collective knowledge from our customers to develop a framework and set of best practices to ensure that all of our customers are successful with their digital initiatives. We call this framework the Digital Execution Roadmap. Roald Kruit Co-Founder and Head of Digital Execution Practice at Mendix Table of Contents Introduction........................................................................................................... 4 How to implement bimodal IT............................................................................. 6 Best practices for getting started with digital execution................................. 11 How to organize your first Mendix team.......................................................... 16 Best practices for applying agile within your mode-2 team........................... 21 Prepare the business for rapid, iterative development................................. 23 Why celebrating success is crucial..................................................................... 26 Key requirements for your mode-2 platform.................................................. 27 Transformation value management................................................................. 28 Conclusion........................................................................................................... 30 Introduction One of the biggest challenges companies face today is how to evolve with the digital era to stay relevant. Technology trends like the Internet of things (IoT), big data and machine learning are reshaping entire industries. These trends are creating enormous opportunities to transform their internal operations, customer experience and even their underlying business models. The CIO’s biggest challenge driving digital innovation is not technology, but leading change. According to Gartner, the biggest barriers for leading this change are skills and resources, funding, culture and structure of the organization, and IT-business alignment. Digital execution requires new approaches and unprecedented collaboration between IT and business. For any organization faced with the need to innovate quickly in the digital world, it is important to stay clear of a one-size-fits-all strategy and instead implement a bimodal IT approach. A bimodal IT strategy calls for two parallel modes: Mode 1 recognizes that there are areas of the enterprise that have more certainty, clear objectives and a predicted plan. Mode 2 recognizes that in other areas of the enterprise, requirements are unclear and changing, and things are less understood at the start. This guide outlines a proven, best practices-based approach to getting your digital execution underway, from how to implement a bimodal IT strategy successfully to addressing the Portfolio, People, Process and Platform aspects of a successful digital execution. You’ll have everything you need to deliver your first highvalue projects in an unprecedented period of time, while laying the foundation to structure and scale your digital execution program. 27% of today’s businesses have a coherent digital strategy that sets out how the firm will create customer value as a digital business.” – Forrester 75% of organizations will have a bimodal capability by 2017. 50% will make a mess of it. How to implement bimodal IT To cope with a high degree of uncertainty, Mode 2 emphasizes agility and speed, like a digital startup. Mendix has identified four key aspects to develop the Mode 2 capabilities required to drive digital innovation. They are called the 4 Ps. Portfolio People Process Platform Portfolio The starting point is all about identifying the right projects, which should combine quick wins and high-value initiatives. Quick wins allow you to realize immediate success and create a wow factor, while high-value initiatives justify broader organizational change. Initially focus on creating a portfolio based on the StartStructure-Scale roadmap (see below), followed by implementing processes to encourage and manage ideation. It helps to include new, innovative types of Smart Apps that are intelligent, contextual and proactive. Download the Smart Apps eBook to learn more. Senior executive buy-in is absolutely crucial for successful digital execution programs. Equally important is defining the person who will drive the program and the teams who will deliver on those projects. This generally entails creating multiple small, cross-functional teams made up of tech-savvy business people and/or business-savvy tech people. People As demand for these teams is often unpredictable, implementing an adaptive sourcing strategy over time is essential to coping with fluctuations and finding the right skills based on specific project requirements. Moreover, an internal center of excellence helps ensure continuity of essential talent while providing shared services and best practices to support the overall program. Process Establish processes for rapid, iterative development and instant deployment in a fail-fast, test and learn approach. While establishing the right governance and DevOps practices is ultimately critical to scaling, the initial focus is on the collaboration between business and IT and the agility required to continuously release and iterate based on user feedback. Platform The platform piece is not just about selecting the right rapid application development platform or IoT, Big Data and Machine Learning technologies. It is also about defining a cloud strategy to minimize costs and time-to-market, positioning the platform in your enterprise architecture to use it for the right reasons, integrating this with your existing landscape, applying best practices (e.g. microservices) to get optimal results, and ensuring security. All of the above should be one coherent architecture supporting your Mode-2 processes, teams and portfolio. Digital Execution Roadmap These 4 Ps are essential to your digital execution, but you can’t boil the ocean. Trying to do everything all at once and immediately focusing on scale will cause you to fail for two reasons: 1. It is too much to swallow at once. The organization simply cannot manage that much change at once. The sheer size of the initiative will inevitably force it to stall. 2. Change is too disruptive without proof. It is exactly for these reasons that Mendix created the Digital Execution Roadmap, guiding organizations through three distinct phases of execution: Start, Structure and Scale. Start Structure Scale Start Scale The Start phase is all about starting small, gaining broader support for your digital execution program by proving the value of your new approach, and celebrating the success of your first initiatives to generate internal PR. You want your first projects to have a WOW factor that is unexpected and high impact so they can be a catalyst for additional projects and spread buzz throughout the company. As Plautus said, “One eye-witness weighs more than ten hearsays – Seeing is believing all the world over.” This is why it is important to pick the right first projects. In addition, you want to ensure the necessary prerequisites are in place, including infrastructure, business case, and the right stakeholders and team. The Scale phase is all about applying greater automation in order to realize the efficiency required to deliver and manage hundreds of applications to become a digital enterprise. This includes, among other things, automating deployment and maintenance to support a large portfolio, automating quality assurance to proactively monitor the maintainability of your projects, and enabling greater reusability by establishing a private app store. With these capabilities in place, you can maximize value and productivity by creating distributed innovation capabilities throughout the enterprise, with multiple teams developing simultaneously. Structure As you move to the Structure phase you begin to focus on formalizing your team and strategy to accelerate digital execution. In this phase, along with building out your team, identifying training needs and deciding on a sourcing strategy are key objectives. It is also important to formalize the methodology used during the first projects to make success replicable. As the number of applications grows, other topics become important, such as implementing DevOps to enable fast, continuous delivery, and focusing on governance and architecture to ensure your apps are maintainable and compliant. Now that you are familiar with the Digital Execution Roadmap and the focus of the 4 Ps in the Start phase, this guide will dive into best practices to get you started with your digital execution, including picking your first projects, building your first team, preparing the business for agile development, and celebrating success. Portfolio Best practices for getting started with digital execution 8 Considerations for picking your first projects The first thing you need to do is select your first projects, followed by assembling your first team. Once these elements are in place, the next steps are to learn agile best practices and to prepare the business for rapid, collaborative and iterative development. The last step is to celebrate success and use it as a catalyst for change. Let’s start by choosing the right first projects to ensure they’re successes you can celebrate. The Start phase is about starting small and celebrating success to build internal excitement—and momentum—for your digital innovation program. It is important to pick the right first projects: ones where you can deliver business value quickly but at the same time, are significant enough that their impact will ripple throughout the organization. 1 2 3 4 It can go live quickly, ideally within 30 days It’s highly visible and will deliver direct business value The business needs to be involved The application has limited external dependencies 5 6 7 8 There’s a desire to take the application into production The requirements aren’t completely specified You tried to build it in the past—and failed It is a Smart App 1. They can go live quickly, ideally within 30 days One of the main goals of the first projects is to validate your ability to rapidly bring new ideas to market. You want these applications to be something that gets the organization excited and open to experimentation. Therefore, it’s important that you identify quick wins that can go live quickly, typically in 30 days. Gartner calls them ‘Island’ projects, as they are limited in scope and can stand alone in production. The key is to show results quickly to create a flywheel effect that accelerates momentum for your digital innovation initiative. 2. They’re highly visible and will deliver direct business value Your first projects should also be highly visible within the organization. They must have the right urgency and executive support, as well as deliver tangible business value. You want to ensure the results get noticed and your success gets shared. You want word of your initial successes to spread like wildfire throughout the organization. Suddenly, you’ll have colleagues banging at your door, saying things like, “I heard you delivered that application in 30 days. How did you do that? Will it work for my project?” 3. The business needs to be involved In addition to executive support, you want projects that require direct business involvement. This isn’t unusual with digital innovation projects, as the requirements are often unclear and need to be refined through collaboration with, and feedback from, the business. The goal is to illustrate the higher level of creativity and collaboration facilitated by this new approach. A common theme is that user involvement in the development process leads to much higher acceptance. And while this collaboration is important to delivering on the core business requirements, it is also about uncovering those small features that aren’t known at the beginning of the project but ultimately determine the difference between average and great user experience. One word of caution: limit business involvement for the first projects to a single department! The ability to make decisions quickly is crucial. If you have to get consensus from multiple departments, with conflicting needs and priorities, this will slow the project down. Go live in 30 days 4. The applications have limited external dependencies To deliver applications quickly, in as little as 30 days, you need to limit external dependencies. The productivity advantage offered by a platform like Mendix can be quickly mitigated by external factors over which you have no control. Examples include: • Integration with existing systems, particularly those where APIs aren’t defined. At one client, it took three months just to get access to their back-office system. You simply cannot wait that long. • Deployment infrastructure. It’s not uncommon at large companies to wait two months for the required hardware. For this reason, deploy your first application in the Mendix Cloud. With one-click deployment, you’re able to remove all friction from the deployment process. Excel or CSV files. Once the project is successful, you can go back and optimize the process. 5. There’s a desire to take the applications into production Another important consideration is that you can take the applications into production. You will gain a clearer picture of the time to market advantage. Plus, you will help your internal PR efforts with a live application that’s delivering real business value. (As an aside, starting with a prototype might lead others to believe this approach is only suitable for prototyping, selling the impact short.) If you decide not to take an application live, the decision should be made for business—not technical—reasons. For instance, a Mendix customer built a • Industry regulations. Often, application needs emerge in response to new regulations. However, if all the requirements aren’t available, you’ll be forced to wait, causing project delays. For your first project (MVP), instead of building direct integration that might slow down the project, it is important to be pragmatic and use less refined methods such as importing and exporting customer self-service portal in six weeks, only to discover a week before go-live that their biggest competitor launched a mobile app. They delayed the launch a few weeks to build 6. The requirements aren’t completely specified As discussed above, digital innovation projects are often marked by unclear business requirements. Don’t worry; this is a good thing! For your first projects, it is better to define a high-level goal or purpose, versus detailed requirements. Then, your team can capture and refine requirements using an iterative development approach. The process of getting from idea to production is traditionally a lot of work, so when your users see an idea come to fruition in just 30 days, they will be amazed. 7. You tried to build it in the past— and failed It may sound contradictory, but good first projects are often ones that your organization previously failed to deliver. This will really open eyes and demonstrate the value of this approach. 8. They’re Smart Apps their own mobile app. This business decision led to a better outcome. To ensure that apps deliver the best possible experience to the user, they should be intelligent, contextual and proactive – Smart Apps. For example, Waze is a navigation app that is smart and personalized for the user because it knows where you are in real-time, knows whether you are in transit and knows when you typically arrive to work in the morning. It combines contextual and historical data with real-time traffic and weather data to optimize your commute. For instance, a Mendix customer initially failed to build an application that calculated the price of custom DNA. Because the algorithm was so specific to the business, the .NET developer wasn’t able to grasp all the nuances. Using Mendix, business and IT were able to collaborate much more closely and a first version of the application was delivered successfully in a few days. It is almost impossible to find projects that cover all eight considerations. To break down the priorities, the project must be highly visible, involve the business and be built quickly. The project should result in a desire to take it into production, ideally have limited external dependencies or no complete specifications. It is nice to have a Smart App or to choose a project that you have failed to deliver previously. Furthermore, the more you progress from the Start phase to the Structure phase, the looser these requirements become. For example, you can select applications with multiple integration points. Your first projects shouldn’t focus on things like scaling or operations. Ultimately, the focus is on delivering business value quickly, in an experimental way where creativity and close cooperation between business and IT are central. Lastly, it is important for your first projects to deliver a WOW factor that is worth celebrating. A wow factor is By picking the right projects you will illustrate several important things: You can release applications in an unprecedentedly short time to market. You are able to work with agile processes and feedback cycles. Business and IT can effectively collaborate to deliver new innovations. Your new approach is a repeatable process, not a one-off success. You can achieve results with limited resources (small teams, low cost). You will show continuous improvement using a fail-fast learn-fast approach. achieved by building something with high value that is unexpected: whether the app itself or a cool feature. Other people throughout your organization should come to you, asking you to apply your new approach to their problems so they can share in that success. People How to organize your first Mendix team In addition to picking the right projects, you also need to find the right people for your initial team. The following are some tips for building your first Mendix team to tackle your first projects successfully. Start with a small team of no more than three people For your first projects, it is important to limit your dependencies and keep your team small, no more than three people. Ultimately, we’ve found that it is easier for a few people to learn a lot in a short period of time, than for a large group to achieve the same results. A small team ensures that you can deliver new applications quickly, avoiding much of the miscommunication and delay associated with larger development teams. There are plenty of examples promoting smaller teams as a means to encourage productivity and creativity—for instance, Amazon CEO Jeff Bezos’ “two pizza rule.” Ultimately, the smaller the team, the more brainstorming and peer review, which drives the group to further improvement. One pitfall to avoid is assigning a different team member for each project role. Each member can be responsible for multiple roles. Instead of a formal structure, team members take on work based on their areas of expertise. For example, you don’t need a dedicated Scrum Master for your first projects, as the lead developer can fill these roles on top of his or her existing development tasks. Once these three people are up to speed, you can add two to three more people and then split them into two teams so you have multiple teams developing and maintaining multiple applications. Keep in mind that because these initial people will be at the heart of your Center of Excellence, they should be A players. Focus on the process and collaboration, not technology In your initial projects, you need to show results quickly and justify the continued use of a new approach (the platform). With this in mind, you need to find a balance between hands-on learning and speed to market. Start by working with an experienced Mendix business engineer. We’ve found that it is easier for a few people to learn a lot in a short period of time, than for a large group to achieve the same results." Work together onsite with the business Find people you want to solve business problems The most effective Mode 2 teams are onsite together, ideally located with the business, working through frequent iterations based on user feedback. Your development resources need daily access to business stakeholders so that they can discuss progress, review changes, and ensure everyone is on the same page. It’s all about enabling creativity to solve business challenges faster. Moreover, by keeping your team close together, you can keep the group excited and motivated to keep showing results. Use coffee breaks to work together so you are not disrupting the business. In addition to keeping your team small, you also want to find team members who care about solving business problems (rather than people who prefer to build solutions based on detailed requirements). You also need to find people who have a “can-do” attitude. This is important because there will be many obstacles to overcome due to existing processes and the culture of the business. The team needs to be made up of people who won’t give up and who will always find a way to make things work. As Thomas Edison said, “Genius is 1% inspiration, 99% perspiration.” Genius is 1% inspiration, 99% perspiration.” Look for people who want to test their limits, have some technical acumen, but also understand business challenges. A host of individuals are able to successfully make the transition, coming from business analyst, UX, front-end web design, and business intelligence backgrounds. In the end, selecting the right team is the cornerstone of success, not just for your first project but for your entire bimodal IT program. Two-pizza rule: The smaller the team, the more brainstorming and peer review, which drives the group to further improvement. Use coffee breaks to work together so you are not disrupting the business.” Mendix Developers come with all types of skill-sets Nicolas Delord: Java Developer turned Business Analyst turned Product Owner and Creative Technologist with the ADP Product Incubator, with experience in software development and UML models. Julio Salazar: Moved from business analyst to development lead and is now Senior Business Solutions Engineer at Digital Risk. MENDIX MENDIX CERTIFIE D Pim van der Noll: Mendix Business Engineer at Appronto, with experience as a programmer, coder, project designer and experience with model-driven development. MENDIX MENDIX CERTIFIE D MENDIX CERTIFIE D MENDIX CERTIFIE D Marcel Groeneweg: Technical Consultant at Synnobsys with over 25 years of development experience across a number of platforms, languages and projects. MENDIX MENDIX CERTIFIE D MENDIX CERTIFIE D MENDIX CERTIFIE D Process Best practices for applying agile within your mode-2 team Now that you have set up your Mode 2 team, they have to deliver their first app in this new method of working: rapid app delivery. While Agile methodologies like Scrum are a good starting point and a critical component of digital execution, not all Scrum principles work in practice with Mode 2 organizations. To ensure that you are properly applying Scrum within your team, focus on the following best practices. Start with shorter sprints Divide work based on user stories Scrum typically calls for two to four week sprints. However, because Mendix offers significant productivity advantages over traditional approaches, you should cut that in half. Otherwise, assumptions made by developers early on can really propagate four weeks later when you finally demo the application. At the beginning of the project, hold weekly sprints to facilitate rapid discovery and refinement of the business requirements. Then as the application starts to take shape, you can move to twoweek sprints. Your recently selected small teams of 2-3 Business Engineers can do 80-90% of the work themselves (thanks to Mendix). Then, when necessary, you can bring flyin experts for specific technical issues like integration or performance tuning. Instead of organizing around technical responsibilities, divide work based on user stories. Give people full ownership of their requirements, versus only being held accountable for 20% of each requirement. Make sure to demo each sprint Allocate time to process user feedback Systems design can be a very abstract exercise. Two people can literally sit in the same room for hours and think they are talking about the same thing, when in reality, that are on completely different pages. That’s why it is crucial to show a good working demo during each sprint review meeting. The demo should help validate existing business requirements and uncover new needs. In your sprints, you should allocate enough time (approximately 30%) to making user-driven enhancements, versus strictly delivering new features. The business is used to not being listened to in development projects. You want to set the tone that they are being heard and that you are able to incorporate their feedback remarkably quick. For the first time, they will feel they can truly make an impact on the project. If there is nothing to show, that is a red flag, as the team may be too focused on a generic technical level instead of building functionality that supports the business goal. At the beginning of the project, hold weekly sprints to facilitate rapid discovery and refinement of the business requirements.” Process Prepare the business for rapid, iterative development Your Mode 2 team is now prepared for agile development with the right process and attitude to work together with the business to deliver the app. However, if the business is unwilling or unprepared, the effort is in vain. You also need to prepare the business for rapid, iterative development. The following are some guidelines for changing the culture of IT and effectively engaging the business in rapid, iterative and feedback-driven development cycles. Focusing on four key project meetings – Intake, Kickoff, Sprint Review and Retrospective – these guidelines will address why and how to perform the following: • Define and maintain a constant focus on the business goal • Define clear rules of engagement for how you will work together • Actively show that you are listening to the business • Work together to continuously improve IT-business collaboration To make the above guidelines more tangible and executable, Mendix has developed a set of best practices and necessary workshops/meetings. Digital innovation happens at the intersection of a business person with a good idea and someone with the technical aptitude to bring it to life.” 1. Intake Workshop 2. Kickoff Workshop This workshop is where the real collaboration begins. The purpose of the intake workshop is to define the project business goal—not what you want to build, but what you want to achieve. The meeting should include the following people: The kickoff workshop should cover several topics, including project roles and responsibilities, a high-level delivery plan, agile awareness and a lean-and-mean Mode 2 governance approach. In terms of business engagement, start by sharing the strategic business goals and application goals, as defined in the intake workshop. Then show how you are going to make the project a success by defining clear rules of engagement. • The Mode 2 sponsor: The leader of the Mode 2 initiative, who can articulate the strategic value of the new approach. • The business owner: Who can describe the problem the application should address. • Power users: A subset of end users, to define requirements. While the business owner plays a crucial role, it is important not to overlook the value of including power users. They have firsthand knowledge of the organization’s challenges and needs. This type of interaction will help create a different attitude towards IT and set the stage with the rest of the organization. While this workshop alone won’t reverse years of distrust, getting the business to think “this just might work” is a victory that you can build upon. Once you have defined the new rules of engagement, work out the first 10-20 user stories as a team. Go through the exercise of having one person write a user story and someone else interpret it. This helps to create a shared vocabulary and understanding, including a definition of “ready” that indicated when the team collectively feels a user story is ready for development. As a last step, prioritize the user stories for the first development sprint. 3. (1st) Sprint Review Meeting In each sprint review meeting, but particularly the first, it is critical to show a good working demo. • Show how you solve business problems. Don’t just demonstrate features; tie the demo back to the business objectives and challenges shared at the onset of the project. • Make sure the UI looks good. Users will judge the book by its cover, even early in the development process. Make sure they don’t tune out because you have underinvested in UI. • Use good demo data. The data needs to be representative so that the demo feels real to business users. They will start to get excited for the impact of the new solution. 4. The retrospective should look back on the project, including successes and lessons learned. • Did the project achieve its business goal? • Did you have the right people on the team? • How well was the business engaged in the process? Embrace all feedback, whether it’s perception or reality. Again, let the business know they have a voice and that their input is vital to improving future projects. Seek their advice on how to develop a more structured Mode 2 approach that further enhances engagement and collaboration with other business units. One of the most important questions to ask the business stakeholders in the retrospective is “how would you tell your friends/colleagues about this project to make them enthusiastic?” This elevator pitch is great fodder for internal feedback and celebrating success, with the goal of implementing this approach more broadly across the organization. The retrospective should also act as input for celebrating success. It is especially important to capture any quotes during this process to share at the celebration. Remember, for digital execution to be successful, the business must be actively involved throughout the project lifecycle. To effectively engage the business, you may have to reverse years of perception. The key is constant communication and proof. Once business users see that you have done what you said you would do—and that they can have a significant impact on the project—they will quickly embrace this new approach. Your initial applications should become a catalyst for change throughout the organization. To ensure the organization knows about the successes of the apps and understands their value, you need to celebrate success. Process Why celebrating success is crucial When you celebrate success you generate internal PR— creating awareness for the value you’ve delivered and what it means for other individuals and departments across your organization. The celebration will drive executive sponsorship, broader support and attract new talent. According to McKinsey, “Involvement from company leaders is critical. Companies with CEO sponsors are twice as likely to be high performers as companies whose CEOs are not directly engaged in digital”. • Invite as many people as possible, not just your development team. • Host the party in a central location so other departments take notice. • Bring the largest cake you can find with project details, it is a great conversation starter. • Make sure your most senior sponsor is in the room to reinforces executive. People like to be associated with success and when they see it, they will very quickly want to be a part of it. This is especially true for business unit chiefs, who may not understand the inner workings of technology but will be motivated to replicate the success of their peers. Here are some tips to maximize the impact of your internal celebration: • Present the results of your project to your captive audience. By celebrating your successes, you will show the rest of the organization that this new approach is real and effective, helping to create widespread buy-in and support. In the process, you will almost always identify new project ideas you weren’t aware of, creating a flywheel effect that allows your digital execution program to take off. Platform Key requirements for your mode-2 platform Though it is often tempting to think about the platform in its entirety right from the start, because there are so many unknowns, including proof that the organization can actually adopt this new way of working, it is better to wait until you have your first results and learnings. It is for this reason that we have structured the Digital Execution Roadmap with three different phases. In the initial Start phase of your digital execution, most of the platform considerations, such as reusability and best practice patterns, are not immediately relevant. Although, the Start phase is an excellent time to start exploring cloud, and to use this knowledge as input for strategic choices in the future. Use this time to experience the benefits of instant provisioning, not just of the application environment, but all the software needed to support the entire lifecycle, from project management to repositories. Learning more about how easy it should be to deploy and operate apps shows how developers can do this themselves. A key element will be to implement DevOps in a later stage. Last but not least, your organization can begin to understand the security features of cloud, and you can assess how this will fit into your existing security framework. The Start phase is an excellent time to start exploring cloud. Transformation value management Rob Llewellyn Founder of CXO Transform and THRIVE Digital Business Transformation After the celebration, the next challenge is to quantify the value of your digital program. While many in your company might be excited by the perceived value of innovative digital solutions, others such as the CFO and line-of-business leaders need to stay focused on business value that can be measured. Sweeping statements of digitization and nebulous notions of new value won’t be enough to satisfy leaders who need to report numbers to their Boards. Despite widespread acceptance that social, mobile, analytics and cloud should have a place in every company’s future, it’s wise to demonstrate how the business value of digital solutions can and will be managed and measured. As the role of IT departments evolves, so too should their capabilities to manage and measure value. Measuring Value to Win Executive Hearts and Minds Start by identifying the value drivers that your digital solution can contribute to, then determine the current status of the value driver. Only by doing this will you know how your new digital solutions are impacting the business. As the role of IT departments evolves, so too should their capabilities to manage and measure value.” If you need to prove the quantitative impact of a new app on the business, you need to capture the data relating to customer behavior to identify how, when, and where the app influences customers at each step of their journey. Next you illustrate how your app has increased customer engagement and satisfaction, and how it also might have led to improvements in operational efficiencies. Establish KPIs, benchmark them, then define the value potential of your new solutions. When your digital solution is in production, report its return-on-investment and forecast the benefits for the next 2 to 3 years. With the right choice of digital solutions and some basic value management, you can be sure to whet the appetite of not only the workforce in general, but also that of executives. Becoming an innovative digital enterprise cannot be done in a single day. There is a natural tendency to proceed with caution, but Hans Luijendijk, director of business enterprise architecture and strategy for KLM, says “Just do it” when it comes to building your first project and getting those first results. Showing off the WOW factor is the best way to prove the value of this new way of working. The Digital Execution Roadmap is set up to help you take your business through the right steps to digital success. After reading this starter guide, you should have the information you need to take your business through the Start phase and one step closer to becoming a digital master.
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.7 Linearized : Yes Language : en-US XMP Toolkit : Adobe XMP Core 5.6-c138 79.159824, 2016/09/14-01:09:01 Create Date : 2017:09:14 13:56:54-04:00 Metadata Date : 2017:09:14 13:57:38-04:00 Modify Date : 2017:09:14 13:57:38-04:00 Creator Tool : Adobe InDesign CC 2017 (Macintosh) Instance ID : uuid:ddcad2ba-f231-3840-9a4e-7e3e321249bd Original Document ID : xmp.did:6989ac2f-2b23-46bc-8ec6-011ad59a11d3 Document ID : xmp.id:226162b2-fbcc-4ad9-aad3-c6261524c972 Rendition Class : proof:pdf Derived From Instance ID : xmp.iid:26c50006-3e29-416f-bdb0-8ffd08d1f645 Derived From Document ID : xmp.did:742c7f4f-5ff7-45e8-8a6a-f0b7dc280978 Derived From Original Document ID: xmp.did:6989ac2f-2b23-46bc-8ec6-011ad59a11d3 Derived From Rendition Class : default History Action : converted History Parameters : from application/x-indesign to application/pdf History Software Agent : Adobe InDesign CC 2017 (Macintosh) History Changed : / History When : 2017:09:14 13:56:54-04:00 Format : application/pdf Producer : Adobe PDF Library 15.0 Trapped : False Page Layout : SinglePage Page Count : 30 Creator : Adobe InDesign CC 2017 (Macintosh)EXIF Metadata provided by EXIF.tools