Managing Applications: How much money can you save with a Collaborative Workflow tool?

Transcription

1 Managing Applications: How much money can you save with a Collaborative Workflow tool? Abstract In recent years the application has become king. For a business to remain competitive it needs to manage applications and their lifecycle as efficiently as is possible. With the rapid rise in mobility it s imperative that organisations can be agile in their response to application management. In this white paper we will explore what value can be added by using workflow tools for application management. Initial Request To run a business effectively your organisation will require new and updated applications from time to time. This is typically known as "application churn". The churn volume will vary vastly depending on the organisation's size and type. Small organisations may only require a handful of new and updated applications each month, whereas very large organisations may have to deal with a few hundred requests in the same period. If you are an IT system integrator then you will have many customers all demanding applications each month. How is this best handled? It depends on where you are right now; you may already have a system and process in place to handle these application requests. Perhaps you utilise a helpdesk/service desk system to log these requests? Perhaps you have an intranet or extranet webpage? Or perhaps it's simply a case of asking the right person (it's all about who you know right?). The key here is that we need to be able make this request visible to the right team or individual. Most workflow tools provide a portal for anyone in the business to raise new requests. Typically users are also able to browse the existing application catalogue (if you choose to enable this feature) so that they can see if the

2 application already exists in the environment, or perhaps check on the progress of their requests. If you choose to use AppTracker, the market-leading collaborative workflow tool, the form is fully-customisable so you can collect the information exactly as you need it. You can ask users for the date they need the software, and if you're feeling really brave you can allow them to set the priority of the request. If you already handle new application requests via another tool (service desk system for example) then you may want to look at using our API to automatically create a new request in AppTracker when one is created in the existing tool. Either way, it's key that your new application request enters your application workflow as soon as is possible so that there are no hold-ups in moving the request forward. Why is this process more efficient with a workflow tool such as AppTracker? Centralised and standardised software request process End-users can search the existing application portfolio to help minimise duplicate requests API allows integration with existing systems Based on our experience you can make an approximate time-saving of 20% if you use a workflow tool rather than or manual methods for managing software requests. Validation One of the benefits in using a collaborative workflow tool is that the right people will be instantly notified when certain events are triggered. For example when we're setting up AppTracker we make sure that the team who validate new software requests subscribe to specific notifications. This means that they will receive an the instant that the request for Adobe Photoshop is submitted. Once an application has been requested there should be some form of human intervention to validate that the request is something the business wants to proceed with. Does the requested product duplicate functionality in an existing product? Is this the right version of the product for the existing desktop/laptop/tablet/server build? Is a new license required? Once a yes/no decision has been made, this request needs to be updated accordingly. If you're using a workflow tool such as AppTracker the concept of Accepting or Rejecting a submission will exists whereby an administrator can accept or reject the request as needed.

3 Assuming we accept this request, the application now needs to be passed to the Discovery team. This may involve a short stroll and a chat, perhaps sending an , or in the case of a workflow tool we simply assign the application to the Discovery Team and they will be instantly notified. Why is this process more efficient with a workflow tool such as AppTracker? Administrators can subscribe to instant notifications of new software requests Administrators have rapid access to the existing software estate, so can quickly ascertain if the new request is valid or not Full tracking so previous requests can be reviewed if required Using a workflow tool to centrally validate application requests can save approximately one third of the time when compared to handling the process manually or via . Discovery The discovery process is a critical one. It involves collecting and recording: Installation instructions ("Make sure you enable the XYZ feature and click 'No' when it asks for ABC") Configuration instructions ("After you've installed the application go into the options and change XYZ") Licensing details ("The serial number required for installation is 12345") Application dependencies and prerequisites ("This application needs Java Runtime 1.x") Who is the "Application Owner" Who will undertake User Acceptance Testing Known compatibility issues ("This won't work as a virtual app") It very common for organisations to hold some installation instructions for some software titles. There will probably be some gaps where discovery documentation was never created, or perhaps has been misplaced, especially if you haven't been strict with your application management. For the new application requests it's a very good idea to ensure discovery documentation is created for all titles. It's useful if you can setup a template for this documentation so that the discovery team always records a consistent set of metadata for each application. You will also want to make sure that the installation source media is stored in a central repository, and it's good practice to setup a naming standard for the directory structure and filenames. If you're using a workflow tool such as AppTracker then you can setup a discovery template so that the discovery team can record this information consistently. The bulk of applications' discovery information should work well with this template. For very complex installations where large Word

4 documents are required to store the installation and configuration steps, these can be attached to the application in AppTracker. Storing the discovery data in a templated format has one big benefit: it can easily be reported on. For example, it might be handy to understand which applications in our estate have a built-in autoupdate function. The screenshot here shows a "Data Mining Report" where I have queried the entire application estate as to which applications attempt to autoupdate. When managing a large volume of applications this kind of functionality can be a life-saver. The final piece of the discovery jigsaw puzzle is for our discovery team to add some information on who the application owner is and who is going to be in charge of signing off the User Acceptance Testing (UAT). Getting this information up-front is going to save lots of waiting time further down the line. There is a dedicated tab in AppTracker for adding these contacts. If you've used Active Directory as a data feed then we'll be able to automatically these contacts later in the process. Let's assume our discovery is now complete, so we'll pop over and see the packaging team and let them know there's a new piece of work ready for them to get started. If we are using AppTracker then we can simply move this application into "Packaging". The Packaging team will get an instant notification that there's a new discovered application ready for packaging with all the necessary documentation in place. Good quality discovery is an essential part of application management. Using a workflow tool won t necessarily make the discovery process more efficient, but it builds the foundations to provide efficiencies in subsequent processes. Packaging The packaging team are now aware that the discovery is complete for a new application and it's their job to build a silently deployable package, be that a setup.exe with answer file, VBScript, MSI, or perhaps an App-V package. They may also need to ensure that the application undergoes a basic runtime test to make sure it runs OK once packaged. How do you capture and share all this packaging information? There are many possibilities ranging from simple text files saved in the same folder as the package, to collaborative workflow such as AppTracker. We've been involved in many projects where no packaging notes are retained whatsoever. This generally causes issues further down the line when a rework of the application (update, patch, configuration change etc.) is required.

5 Here's a screenshot of the "Application Details" tab in AppTracker where the packaging information is recorded. Note that AppTracker can be configured to collect custom data such as an internal application ID. This increases the efficiency of the packaging team as it allows them to record packaging related data in the fields, plus add any commentary in the Notes section. If they find any problems with the software they can be added and tracked in the Defects tab. Compatibility testing results can be recorded in the Compatibility tab, and any dependencies can be recorded in the Dependencies tab. Once the packaging work is complete the QA team need to review this application. You may have a dedicated team, or you may use "peer review". In workflow tools we move the application into the "QA" process and the relevant team members are notified that the package is ready for QA. Why is this process more efficient with a workflow tool such as AppTracker? Discovery information is instantly accessible for rapid package creation Custom data (such as internal App ID) can be maintained alongside other application metadata Centralised packaging information database and notes retained for updates/reworks etc Dependencies and defects raised and tracked Using a workflow tool for the packaging phase of application management allows you to save approximately 20% of the time taken if you weren't using such a tool. Quality Assurance (QA) It's really important that organisations document and maintain guidelines for internal packaging standards. The objective here is to deliver applications to the business which have a standard look and feel and which operate in a predictable way. Here are the reasons we feel this is critical for all organisations: It improves the user experience because shortcuts are presented in a consistent manner It reduces support issues because there is a consistent approach to each application's look and feel It eases support of applications as files will be installed into standardised folders It allows you to locate and manage the application source files more easily due to standardised folder names and structures

6 It can help to retain a clean user desktop reducing support issues The internal packaging standards will differ for every organisation, but generally speaking they should cover: Application package format (MSI? App-V? Setup.exe?) Application naming standards (Include the vendor name? Include the version?) Application shortcuts standards (Are desktop shortcuts allowed? Should readme.txt and Uninstall shortcuts be removed?) Application installation folder (Always install into "Program Files"?) Automatic updates (Disable?) Uninstallation cleanup (Is it OK for files to be left behind?) Paths and settings (Should all paths and settings be variablised in MSI Properties?) The key objective for the QA process is to ensure that the agreed standards have been met for every package before it gets passed to User Acceptance Testing (UAT). It saves a lot of time if problems are identified during the QA phase as they can be quickly remediated by the packaging team and re-run through QA. If however QA is skipped and the application goes straight to UAT, there is a chance that the UAT person will miss one of the QA checks (eg. autoupdates weren't disabled). The application will then get deployed out to live machines, auto-update will run and errors may start to appear as the users don't have local admin rights. This will cause support issues, and the application will need reworking and updating on all the machines. That's a lot of unnecessary effort. Most workflow tools provide a fully-customisable QA form which can be used by whoever is handling QA in the organisation. When an application enters the QA process it's simply a matter of the QA person checking each item on the form and filling in the results. They can then give an overall result (Pass/Fail) and move the application to UAT (or return it to packaging). As always the relevant teams will be instantly notified of the change. Why is this process more efficient with a workflow tool such as AppTracker? Standardised QA process which is visible to all Customisable forms allow QA checks to be exactly as required by your organisation Web-based forms allow the QA team to complete the QA checks rapidly Dashboard provides "at a glance" QA performance historically Managing the QA process using a workflow allows you to make a significant time saving of approximately one-third for the reasons outlined above.

7 User Acceptance Testing (UAT) Once an application has successfully passed through the Quality Assurance process we can arrange for the application to be tested by the business (typically the application owner). Depending on your organisation's processes this may involve adding the application to the deployment tool (eg. SCCM) or you may just manually install the application on a test machine. If you are using AppTracker you could trigger a PowerShell script to auto-create the required objects in your deployment tool. Once we have the application ready for UAT we will need to engage with the business. It's quite typical for the person who created the package to handle the communications with the application owner and oversee the entire UAT process for that application. This has a number of downsides: No centralised UAT calendar No standardised form to record the outcome of the UAT Tracking UAT progress is dependent on individual Application Team members Application packaging technicians do not necessarily have the soft-skills required for managing UAT with the business Inconsistent approach to UAT communications (templated ? instant message? mentioned over lunch?) There are ways we can overcome these problems. We may want to a) ask someone in the Applications Team to be responsible for managing all the UAT, or b) have a dedicated person for this role. However both these are expensive options as they either impact productivity (a) or require investment in a new team member (b). A workflow tool such as AppTracker is another possible solution to this problem. Let's take a look at how AppTracker helps with UAT: 1. DEFINE TEST SCRIPTS Depending on the type of application being tested you may require different test scripts. A web application will probably require a different test script than a standard desktop application. AppTracker allows you to create up to six unique test scripts for UAT. Here's a screenshot showing how to build a test script.

8 2. SCHEDULE THE TEST Now we are ready for our application to be tested by the business. If we need to add this application to a deployment tool such as SCCM we might want to automate this via a PowerShell script. This script can be triggered from AppTracker to further streamline the process. To schedule the application for testing we change to the "App Testing" tab in AppTracker and click "New Test". We are taken through a wizard where we can choose: The test script required for this application (web application, desktop application etc) The user who will be testing the application (if an application already has any contacts assigned you can pick these from a list) The Blueprint that this test applies to (a location, office or department typically) The test start and end dates The option to include a calendar file so the UAT dates can be added to the UAT person's calendar The test machine name The option to include an RDP file in the so the user can connect directly to the test machine from their own machine 3. END-USER TESTS THE APPLICATION The end-user will receive a templated from AppTracker notifying them that their application is ready for UAT. Notice that an ICS file is included so the user can add this testing window directly to their calendar. Also note that an RDP file is included which allows them to connect to the test machine and run their UAT without having to leave their desk. Let's assume that the user has connected to the test machine and is testing their application. To record the results of the UAT they click on the "Sign Off" link in the which will open this screen in AppTracker:

9 They can then submit the details of the testing, along with the UAT result which will ultimately be either pass or fail. 4. REVIEW THE RESULTS The Applications Team can now review the submitted test results in AppTracker, including all notes added by the UAT tester. They can view this result individually in the "App Testing" tab, or they can view the UAT results for all the applications in the main Applications grid. Finally, the dashboard in AppTracker 4.5 and later contains widgets where you can view success/failure rates for UAT. Applications which pass UAT will be assigned the team responsible for deploying the application to the live business machines. Where an application fails UAT it will be assigned back to the Applications Team for rework.

10 Some applications will require UAT by multiple areas within the organisation. This can get complex to track manually, but AppTracker can help as shown below: Here we can see that the application "Netxp SMSCreatorMini" has been UATed three times. One user passed it, and two failed it. In a default instance of AppTracker we display this result as "Mixed", however we can easily change this configuration so that this is a "Pass" or "Fail" if desired. Summary Managing UAT in using AppTracker overcomes all the issues previously listed: No centralised UAT calendar. Solved with the AppTracker UAT calendar. Screenshot below. No standardised form to record the outcome of the UAT. Solved with customisable test scripts. Tracking UAT progress is dependent on individual Application Team members. Solved with centralised UAT tracking in AppTracker. Application packaging technicians do not necessarily have the soft-skills required for managing UAT with the business. Solved with templated s for UAT. Inconsistent approach to UAT communications (templated ? instant message? mentioned over lunch?). Solved with templated s for UAT. Why is this process more efficient with a workflow tool such as AppTracker? Centralised UAT scheduling and tracking UAT contains RDP file to allow instant access to the test machine from the user's normal machine Multiple test scripts for different types of application Web-based forms allow UAT feedback to be compiled quickly with just a web browser Workflow tools introduces a significant increase in efficiency for the testing phase of applications. With AppTracker you can save approximately 40% of the time vs manually scheduling and tracking UAT.

11 Live If you haven't previously added the new application to our deployment tool then now is the time. Most workflow tools can assist here in one of two ways: 1. By allowing us to trigger commands to run on a specific event, such as when an application is changed to the "Deployment" phase. This script would typically create all the items in the deployment tool (and possibly Active Directory too) so that the application is ready for deployment to live machines. 2. If the Deployment Team prefer to create the deployment objects manually then they can use the workflow tool as an information source. What is the package name? What is the command line needed for install? What are the prerequisites and dependencies? Workflow tools can answer all these questions without the need for s and phone calls to the packager (who happens to be on leave today). At this point you may be interested in taking a look at your applications journey from request through to "Live" to see how long it has spent in each process and identify any bottlenecks. In AppTracker we can do this using the builtin reports to create a pivot chart. Here we can see the amount of time (in minutes) that the application spent in each process. It's clear that packaging took the most amount of time for this application. Why is this process more efficient with a workflow tool such as AppTracker? Trigger creation of deployment objects (eg. SCCM Application etc) via PowerShell scripts Centralised application knowledgebase provides deployment team access to all necessary information to create deployment objects In our experience you can save approximately 25% of the time getting the application into Live by using a workflow tool such as AppTracker.

12 Retire At some point applications will no longer be required. Managing standalone application retirements is not a complex task, but it's important that everyone in the organisation has visibility of what is live, and what has been retired. This is particularly useful when new applications are being requested as it may be that a retired application can be reinstated, rather than it being created again from scratch. One area where a workflow tool can add value to the retirement process is where application dependencies are involved. Let's say we have a version of the Java Runtime which is a dependency for seven business critical Java applications. How do we put controls in place to trigger alerts if someone decides to create a new package for the latest version of Java Runtime, and retire the original Java Runtime package? With AppTracker we can run custom scripts on a schedule. In this case we'd write a script which runs daily and looks for applications with are: a) A dependency AND b) Process is set to "Retired" As soon as the original Java Runtime package is set to "Retired" in AppTracker, it will meet the above criteria an alert will be sent out to the relevant teams. This Java Runtime upgrade can hopefully be stopped before it goes live, saving potential problems for those seven business critical Java applications. As described above, there are some real benefits to using a workflow tool when retiring applications, however in most cases these do not result in a time-saving. Conclusion We have explored all the common phases an application passes through in its lifecycle. In six of the eight phases we have shown how introducing a workflow tool can save anywhere between 20% and 40% of the time taken. To get an idea of the real savings you can make please refer to our ROI Calculator: