Our 3 Step Process to Reducing Implementation & Maintenance Time by 20-100%!

00:00	Welcome to our presentation on maintenance for Hyperion and Oracle cloud applications. We put this presentation together and presented it at at Kscope and had quite the turnout. So we wanted to make this content available for everybody since many of the attendees saw a lot of value in it.
00:26	So just to get started I won’t go into all the detail on the abstract that we put together for the conference but just to give a little bit of background on why we put this presentation together. A lot of organizations struggle in the implementation and maintenance of applications where there are many tasks that are very routine or mundane and take a lot of time and not a lot of organizations think about what options do we have to automate our whether it’s our maintenance whether it’s the implementation and how do we save time how do we ensure that if our
01:11	Maintenance team were to leave the company and we needed to hire somebody else that we would be able to get them up to speed very very quickly that we’re going to talk about three things in this presentation. One the maintenance nightmare. So I’m sure a lot of this will resonate with with many of you and we won’t have to spend too much time going into detail on the different issues that you may face along the way.
01:42	The second that we’ll talk about are the three steps that we perform here to reduce implementation and maintenance time by 20 percent or more in some cases we’ve seen 50 60 70 percent reduction or even more or up to 100 percent reduction in in many of the tasks that that we do.
02:06	And lastly we’ll give you a behind the scenes look on the software that we’ve put together and many of the ones on our roadmap in order to implement and maintain Oracle applications better faster and cheaper than than many of our competitors before jumping into the presentation just to give you a little bit about my background.
02:31	I’ve worked in technology for over 13 years now in a variety of capacities from a support perspective from implementation from maintenance as well as support. As I’ve said in organizations ranging in size from small businesses to a large Fortune 500 companies I’ve I really value education and I like to stay on the cutting edge of technology so I’ve achieved over 75 certifications throughout throughout my career and I’ve worked for companies such as all over Weimann peloton Consulting Group and Ernst and Young.
03:15	Prior to starting my own firm the learning analytics. Have a U.S. patent pending on automating enterprise software inventory and testing. So some of the things that we’ll talk about here are related to the intellectual property that we’ve we’ve built along those lines and then in terms of implementations we do EPR MBI master data management robotic process automation analytics managed services we do have services around automated testing for your applications whether that’s regression testing or functionality testing as well.
03:54	And we also do custom software development so jumping right into our presentation here in terms of maintenance. There are a lot of tasks that application administrators have to do whether keeping documentation up and up to date modifying components testing components reconciling data adapting to future requirements troubleshooting issues and the list goes on and on.
04:21	I’m sure there’s probably two or three times what what we’ve listed here and it leaves little time for system improvement and as a result a lot of our clients and organizations that we talk to will tell us that application functionality is pretty much stayed the same over the last five years 10 years in some cases 20 20 plus years.
04:46	And that’s because nobody has time to go and actually improve the system because so much time is spent on the maintenance aspects of it. And as we look through the typical implementation lifecycle a lot of projects that start up are you know doomed in some regards just because when you look at the lifecycle you have your requirements your design your build testing and deployment many of the functionality components aren’t actually fully tested until you get to the testing phase.
05:26	Some organizations try to do an agile approach to implementations and you know the part that gets done Agile is your requirements designed and build. But once you get to the testing phase that’s when you’re ironing out a lot of the kinks and and doing user acceptance testing that’s when you start training the end users.
05:49	And as a result you may have a project that’s taken several months to build and design and you’re trying to communicate the issues the any of the knowledge transfer all the testing the things you learned along the way within the last couple of weeks of the project whatever their scope creep or project are running over budget.
06:16	The first thing you get cut are your documentation your your knowledge transfer. So a lot of projects are set up for failure from the beginning. That’s because there isn’t an adequate handoff that that’s happening. George towards the end of the project one of the projects that I’ve worked on for a top 10 global bank. They were hit from their auditors with a significant deficiency.
06:48	And it wasn’t because the auditors didn’t think the numbers were correct or didn’t have confidence it was because the documentation around the the financial reports wasn’t all there. Nobody could point to one document that said here’s how our data gets from point A to Point B. There were plenty of subject matter experts that were able to talk to you how to do it but there wasn’t a piece of paper out there.
07:16	That said here here are all the hops the data goes through here all the controls we have every step of the way. So as a result of getting this deficiency they were told that unless it was resolved by a certain date they would not be able to issue a dividend to the shareholders. And as you can imagine you know a stock that pays dividends a longer able to pay dividends that stock price is going to plummet as a result.
07:46	There was a huge undertaking to go and resolve this significant deficiency over three hundred million dollars was spent in consulting services over a three year period just to document how that how that data gets from the system of origin or system of record all the way to the final reports that get released in investors. So as you consider the return on investment you know things like documentation have a very small perceived value.
08:20	But if you don’t do it right you can end up paying big in the event that you don’t have the documentation when when it’s requested so thinking about you know regulatory implications and having that appropriate documentation. When was it last updated. Because you know sometimes you have robust an extensive documentation when the system is released and then 10 years later it’s changed you know 20 different times and nobody bothered to go in and update that documentation because they didn’t have the time.
09:00	And also just having it everyone has to know where it is to be able to point to it where you know if an auditor or somebody requests it and you can’t easily find it then you know there there isn’t much you can do there and then finally considering the monetary as well as the non-monetary costs things like reputation risk investor confidence you know stories always get twisted where you’re not having a piece of paper that points to everything can can get twisted into.
09:35	Well this bank doesn’t know. What’s wrong with their numbers and they’re somebodies fudging numbers. And all of that. So you just want to make sure that you’re taking into account into account all the different considerations that you have. In terms of impact I know we touched on many of these I won’t go and read them one by one.
10:01	But some of the major impacts are a time where you know time’s a wastin troubleshooting issues that you know it may have been avoidable if you had a document where you had the common types of issues and you have a new admin that comes in and could easily just you know read that document and come up with it if you know in terms of cost. There could be increased costs due to that time wasted.
10:28	Some additional ramp up time that may be needed if you’re if you’re bringing in a new team a team member on board quality and reliability we all know that the hundredth time we do something the quality is much better than the first time we go and do it. And especially if we have you know a step by step document help us that that quality and reliability goes up and you know when somebody goes in and starts making mistakes and takes a lot of time to fix the issue it can impact the user confidence in the system and then finally the auditors there may be increased scrutiny when have missing documentation and there are other implications as we talk through as well.
11:15	That’s the first part of the presentation. The second part is the three steps that we go through our methodology on how we can reduce implementation and maintenance time by 20 percent or more in some cases up to hundred percent so let’s jump right in so our methodology is very simple. It’s three steps. We start with a task. We break that task down into steps recognizing that not every step is something that can be automated.
11:47	So you just automate what we can and what we find is that many of our clients many many people that we interact with will tell us oh well you know that task can’t be automated because this little tiny piece can’t be automated so we’re not even going to bother trying. And what happens is that what you find is maybe there are bits and pieces that that can’t be automated and then have to be manual.
12:14	But if you automate what you can it can save you a lot of time a lot of money down down the line. So we focus on breaking it down into chunks and automating those pieces and you know we’ve seen we’ve seen great results from it. You know just recently I was I was on a project where you know the entire team had to work work all weekend because the project was falling a little bit behind.
12:44	And you know we went through the steps the team lead said hey you know we we were looking at ways to automate this. It can’t be automated. So we need the entire team to spend this whole day and go through these eight steps. I looked at the steps I saw well you know yeah it can’t be automated because there are some pieces that just need you know human judgment but you know six of eight tasks can be automated. So why don’t we just do that piece.
13:13	So within an hour or two we sent down an email with hey you know we automated steps one through six for everybody. All you have to do are steps seven and eight. And as a result the you know the entire team and this was over 10 15 people. It took two hours instead of eight hours. And when you think about that in terms of cost in terms of time savings I’m sure a lot of people would prefer to have their weekends to be able to to do their own things.
13:47	You know we were able to add significant value just just by looking at all the things that that we can automate instead of looking and focusing on the things that we can’t so we’ll walk through a few examples here of how we’ve used this this methodology and how we’ve broken down the tasks and automated pieces to to save time and to and to save prosper for our clients. So our first use cases with DRM.
14:19	So as Oracle’s data relationship management master data management software we went into a client and they had no documentation. They couldn’t find it. They said that you know the solutions changed 100 times since it was even if they could find it and they ask us to perform an assessment of whether DRM could be used to facilitate a chart of accounts redesign that they were going through.
14:50	So we the result was we built some software. And you know we were able to use that for this particular client where within the first 10 minutes we got a full inventory of their DRM environment and we were able to use the remaining time reviewing that documentation and determining the readiness for the chart of accounts. Redesign.
15:15	So within a week or two we were able to have a full understanding of all the components they had the dependencies that were there so that we could go and start.
15:31	We didn’t have to go and spend weeks documenting their system or you know guessing at various points whether whether it could and then during the project we had some other teams that were downstream systems that would be taking hierarchies from DRM and they requested you know four times or more that we provide them documentation of the different properties that are available in DRM and other hierarchies things like that.
16:07	And you know as many of you know when someone’s requesting documentation during the build phase of a project it’s usually not started yet. And the answer to those requests is typically well you’ve got to wait till the end of the project for for us to give you the documentation or we’ve got to stop all our build activities and start documenting everything.
16:31	So just being able to click a button or a couple of buttons and you know we were able to give them a full inventory of everything that was in DRM within within minutes rather than within days or weeks. So you know how is this possible. Do we have some dark voodoo magic that you know that we’re casting in order to complete these tasks. You know you should probably know the answer is No. You know how we do it is we use technology we break down the tasks.
17:03	Into some tasks and we we automate the piece that we can. Right. So when we think about inventorying and assessing DRM there are three main components that there’s the actual creating the inventory and documentation. Right then there’s that we’re reviewing it to determine whether it’s fit for use. And then there’s the design work of designing the overall architecture of how DRM would be used going forward to support the chart of accounts redesign.
17:36	So building in the inventory and documenting we looked at that and said well why can’t we automate that piece. So what if we automate that piece. That’s a part that usually takes you know a week or two of somebody going in and looking at what’s on the screen typing it out. There are a lot of errors that can be made when you’re doing it manually and then reviewing and designing Well that’s something that you know someone with experience and taking into account the client’s requirements that it just can’t be automated at least at this.
18:13	At this time. But building that inventory is something that can be automated. So let’s focus on building that piece of it and then we can you know that that alone will cut two weeks off of our second use case and we’ll show you an example when we get to part three here. Gambling the different products we have.
18:45	I’ll show you what you know what the result of that looks like and how we were able to do that. But I first wanted to talk through the different software that we have use case to also with with DRM is a lot of times when you’re in the build process of the project. It can be challenging and cumbersome to load in dimensions into DRM.
19:12	So we had previously built some software that we used and we were able to bring all the hierarchies for the application in in under a day. And for many of you that work with DRM the planning you know it’ll take a few days to a week to bring in a single hierarchy we were able to bring all of them in on the first day of the project so we worked with a leading utility company.
19:44	So again they budgeted several weeks to load the 10 Hyperion planning hierarchies into DRM. They they budgeted about a week per per hierarchy in order to load those hierarchies into DRM you could do it in one of a couple of ways you can build some action scripts if for those of you that are familiar with with your m.
20:09	You know it or you can load them using imports but as you know there are significant setup times that may be required. There’s some one time efforts that that ends up being throw away work. When you when you after you build them you don’t necessarily need them a second time.
20:34	So what we did here was we used our our software and we had that parent child hierarchy defined we asked the team to build it and parent child format in like an excel file. We were able to show a visual representation of what that would look like when it got into your home before we even loaded it and the software generated the action script that was needed to build the whole hierarchy in DRM.
21:04	Again all the hierarchies were generated in less than a day and there was no throw away work but when we think about how we did it right we took building the DRM hierarchy as our task. We broke it down into three steps defining the hierarchy determining the required fields that we would need to load into DRM and then actually loading to the area. And we looked and said All right well defining the hierarchy.
21:32	That’s something that we could automate we could pull it out of since we were using Hyperion planning as a starting point. We could We could We could go and just pull the hierarchy definition from Hyperion planning in terms of determining the required fields. That’s something that we would have to look at. Well you know what properties are we going to have in DRM what’s DRM going to how is that something that you would need somebody to think about it and to plan ahead so that we looked at and said that’s probably going to be a manual task.
22:05	And then loading to DRM you know generating the DRM file and loading it in and that’s something that could be automated as well. So you know why don’t we focus on the things that we can automate and use that to leverage the utilities there. And then you know the piece that’s manual we can we can leave as a manual task. This is just a screenshot of what the utility looked like.
22:32	Again you can define parent child format it has an Excel look and feel to it you can see the result as the hierarchy. So you know a lot of times as people are going through using Excel for building their hierarchies you can’t quite see how the relationships look because it’s very flat when it’s just in parent child format.
22:59	But here you know you can you can do that and you can edit the hierarchy through the visual as well as through the the corresponding spreadsheet that’s in there and then you just click a couple buttons and you could generate the DRM Action script you can build the hierarchy for you it can build the nodes it can update the properties you can mix and match and and generate your your hierarchy there.
23:31	And as we looked at it we said well we can make this very flexible and you know it doesn’t have to just export DRM Action scripts. It could also generate a file that you use for outline mode utility or yes et cetera. So it’s a very generic tool. One thing that I highly recommend you know is check our Web site and check out our blog periodically because you know many of these smaller utilities that we’ve talked through we’re working on on ways to be able to distribute them.
24:10	We’re just working on some licensing details there because we use some commercial libraries in there. So we are planning on making some of these utilities available for free and we’ll have some content updated when we do release them. So you know please feel free you can subscribe to our YouTube channel you can bookmark our blog and check back periodically because this is one of the utilities that we are planning on releasing our third use case is automating application testing within PBS so many times.
24:51	One of the biggest selling points to going cloud for organizations is that there are tons of there’s tons of functionality that’s updated every single month and for some organizations that sounds like an amazing thing because they said well you know hey we don’t have to go and patch get all the new new features we can use them right away that’s great. But for most organizations they look at that and that scares them because they say well that means that we have to go in and test our applications every month.
25:25	One of the most requested service requests that that’s issued to its Oracle is we don’t want our patches monthly. Can we have them less often. Can we have been ordered we’re you know or less frequent than that and they do that because many organizations don’t have people around that can just go and and work on testing and put aside their day jobs to do it.
25:54	So as we went through we said you know how can we deliver the best of both worlds to to our clients. How can we ensure that that they can get these new features every month or whenever they want but not have to go through the rigors of retesting everything every time. So we’ve been working on a platform to automate application testing.
26:20	Right now we just haven’t heard PDC ask but we’re working on expanding to other products as well where we can automate testing business rules creating members editing substitution variables and so forth.
26:34	In a completely hands off manner so that way every single time a pack is is pushed to your environment you can run these tests and you don’t have to spend time or dedicate people to it to you to get it all in their so every time I’ve told people hey we want to build a you know we’re working on building an automated testing platform you know the the general response has been oh that’s that’s impossible or you know that’ll take you forever to be able to create something like that.
27:12	And you know we looked at it and said look this is an area that has a lot of value there. You know days or weeks of business users time that’s required to test calculations. Right. And no matter how much you try to plan it out it just always happens you know or maybe it’s just me where it always seems to overlap the testing phase of a project with the clothes and getting people getting their ability to commit to testing usually falls falls apart.
27:48	You know when when you start overlapping with with clothes activities and you know testing is often neglected because of the inability to free up users time and you know sometimes that they’re going through and just checking boxes saying that they’re testing because they you know they they don’t have time to be thorough. Other times they’re going through faster than.
28:13	You know than what’s originally planned to try to work around the clothes and you know there can be issues and other other things there where they just aren’t as thorough as as they should be or would like to be. And sometimes they just say hey we don’t have time to do it. And we’ll check the box sign off if you want but. And cross our fingers and hope that it works.
28:42	And the application administrators are busy. You know you’re maintaining other applications. There’s tons of other effort that’s that’s happening and the administrators can even say you know what we’ll take the testing off your hands and do it ourselves because they’re usually short staffed. You know there’s pressure you know from from the business to say that says hey look we want to get this system up and running as fast as possible we want the value from it for the administrators.
29:11	They just don’t have the time to do everything themselves or you know to be able to push changes through. And you know sometimes they they do make those changes rapidly and there’s a significant risk to not only system’s stability but user confidence in the system as well. Right.
29:31	So as we looked at all these things we said well what if we built a platform that allowed the business and technology to create automated test cases for business rules data security substitution variables member creation being able to schedule these tests to run during off hours so you could say hey test this has these business rules overnight.
29:57	Email me an Excel spreadsheet that has the results so that way when I walk in first thing tomorrow morning I can review it and you know and move on to my my daily tasks. And be able to notify through through email of those test workbooks and keep the relevant people informed. Right. And you can keep your auditors happy to where you say to an auditor hey we run this.
30:27	We run daily tests of our system and we push the changes through. We run these. We schedule these daily tasks and we have all the all the workbooks to to prove that the tests are all passed. Chances are they’re going to be much happier with you and maybe give you a lot more leeway then if they ask Hey are you. Are you making tests or are you testing your changes in the system for you to push it to production and you say yeah we do.
30:57	You know we don’t have any test scripts or we can’t find them or whatever the case may be. But you know take our word for it that it’s done. All right. To look at two or two very different ways. When you have those scenarios so as we looked at how would we go about automating such a task as testing calculations.
31:22	We said well you know let’s take an example calculation let’s just if we take everyone back to your algebra classes which I’m sure many of you don’t want to go back there. But we said let’s just take we take a number we add five to it and we get a result Y equals X plus five. How would we what is the process that we would go through in order to test that calculation.
31:50	Right so we go through in a few steps we’d first input whether actual or dummy data into interim value so we would say All right let’s assume X is three. I’m going to push it three in there. I would say well what what would our expected result be if X is three well three plus five is eat.
32:10	So I would expect my result to be a we then run the calculation and and wait patiently as some calculations aren’t just a simple one second execution some of them are very complex allocations that need minutes or hours and you know we’d run that calculation we would query the result and say what did the system get for y and compare it to what we’re expecting it to be of eight.
32:43	And we would say right if we get eight and we’re expecting eight we know the test passed. If we get 10 and we were expecting eight. We know the test failed. Right so we took that we broke it down into steps of inputting data specifying target results.
33:00	Executing that calculation and then comparing the results to our specified target and determining whether whether we have a pass or fail now that we have these different steps we can say right well what pieces are manual versus which are can be automated inputting data that’s something that we would say is is is manual right there is a piece of actually pushing the data to the system which can be automated but the actual coming up with a number to push in the test case is something that someone would have to manually specify and determine right then determining the target results.
33:47	That’s another manual task where you can run through you can create an excel spreadsheet or whatever to calculate the the specific result but that’s something that you would have to review and look at and say Does this make sense for the answers that we said all right well that that could be manual as well. But then running the calculation I don’t see why you couldn’t have a system that that executes the calculation you specify and then comparing the results.
34:20	Well you know if if you get the answer back and it’s 10 and you were expecting eight you know that’s something you could automate comparing 10 to and saying they match. Right. So we have four different steps that we’ve we’ve put in here. You know you can get more granular if you want and break it out further. These are the buckets that we came up with and we determine what what would be manual and what could be automated. And as a result we built a platform where we could automate testing the calculations.
34:55	So it’s done in a series of steps where a user can create a an input grid and the look and feel of that is very similar to smart view.
35:05	So if you’re technical enough to be able to operate a smart new query or technical enough to be able to build your own automated test cases you just enter some criteria like like the name you create the input grid here’s the data I’m going to push to the system then you choose the calculations that you’d like to run you can create a retrieve grid in order to
35:35	enter your specified results that you’d like to compare and then when the test case is run the system will query you know it’ll push the data that you’ve specified to be input it will execute the calculation you told it to execute it will then run your retrieve grid and look at the expected results that you have and compare it to the actual results that are in the system and what it does is it gives you an Excel workbook of that test so that way you can see what are the assumptions that we have what what was imported what was queried and what were the results.
36:18	So here you see the final tab of that where it shows that you know we passed the test based on what we did what we entered so those are the three use cases. The remaining time we’ll just go through and I’ll show you some screenshots of the different utilities that we just talked about and maybe start talking about some of the utilities that were planning for the future so from the DRM standpoint we talked about automating the inventory and docking a documentation aspect of DRM.
36:58	So we actually broke this utility out into into four pieces. There’s inventory creation or documentation. You know we said well where else can we go with this. Based on if we know what’s in the system what other aspects can we automate. And we looked at it and said well we know which components you know what component types may have dependencies on other component types.
37:26	So why can’t we make a search engines where you enter a component that was inventoried and have it tell you here are all the dependencies that you should watch out for in case you make a change. And if you go to delete a component and it’ll tell you many of the components that you know that are mean that sometimes if you modify a component if you’re modifying script logic within a derived property it’s not going to know that you’re making references to two other components there.
38:05	So that great way to be able to create a report that way you could get ahead of any types of issues where you say I want to change this component. What are the other things I should look at or think about. And you know it goes you know infinite levels deep when you’re looking at derive properties that derive off of other derived properties which derive off other derive properties that will actually go in and give you every single dependency you know an infinite number of levels down.
38:37	The third piece is you know if we know what components are in the system well we can also tell you generate your test scripts and tell you what it is that you should test. We know that many things are tested in a very similar way Deri. If you had a derived property you would enter you know a source input value that’s valid for positive testing you could input source values that are invalid for negative testing and as a result we’re able to just generate hundreds of test cases based on what you know what should be tested.
39:14	A lot of times there isn’t much time allocated for generating and running tests while you’re on a project. So if you can save some time and have it tell you what what the test then you could ensure that no one you’re saving time and cost. But also your ensuring that you’re testing everything that should be tested and it’s not just something that was cut short because you know due to due to the timeline there.
39:44	And then finally if the system can tell you what to test why can’t it also run those tests for you and track the results. So some of these features especially you know the test script creation and execution where we’re currently working on it and it’s something that’s coming very soon.
40:05	But some of the pieces like the documentation the dependency analysis those are already done and you know we could demo them to you if if you want to reach out I’ll have my email at the end of this presentation and I’d be happy to walk through any of these cases you know in your environment with your data this is an example of what the documentation looks like so an Excel spreadsheet that just has a series of tabs for each component type.
40:43	It’s all filled Turnbull’s sortable and give you a great insight to add to what you have. This is an example of the dependency analysis module we’re working on the visuals of it so you know it just looks pretty plain and basic here. But if you type in hey I have a property this custom that each of them name what are all the different components that that reference.
41:17	That particular property and you know you don’t have to guess if you’re going to make changes you don’t have to say. I’m only going to test the things I think are impacted you could go you could run this utility you could see everything that is impacted and you can make sure that you’re testing the right pieces and then in terms of test script execution this is what we have at this point in time we can generate test cases individual steps for each of them do positive and negative testing within the system.
41:57	There’s the example of some properties here where. You may have list properties where you say hey it could be one of these eight different values well if I were to go in and test that what I would do is I would set that property equal to each of those eight different values to make sure that it takes them. And then I would also put in a value that’s not in that list and make sure that it doesn’t take a value that that it shouldn’t.
42:25	So these types of things are what we’re building at the moment where looking at different tests in different ways that we can expand this to make sure that we have a more comprehensive test as well.
42:39	We have some some basic pieces in here but you know as we go we’re definitely moving at a rapid pace to 18 against the functionality and then the automated calculation testing we we talked through that in in third use case there be looked at this and we said well we want to make sure that business users can define their it’s not something where you need yet another tech savvy person with a totally different skill set to be able to go in and do it.
43:21	The setup is very easy. In the event that you don’t know what are the different steps I need to run a calculation test. We have templates that that are built in where you could just go and load them and it’ll tell you you know first thing we’re gonna do is clear clear the data that you’re pushing to the system. Then we’re going to input some data we’re going to run a calculation and then we’re going to test the result to make sure that that it’s working properly so again.
43:51	Easy easy to use in to build the test cases. You don’t need technical skills you can run these tests on demand. You could define a schedule to say run these every day run these every week etc. and you can download the results. You could have them emailed to you. You can hand them over to auditors saying hey we run these tests daily. And you’ll make them very very very happy because not many organizations have that at their disposal.
44:23	And then no excuses for why your testing timeline is impacted. What one of the biggest benefits here too is you can build the test cases as you go within a system with your implementation. Many companies though try to be as agile as they can with with their build process and the team will go in they’ll go they’ll build some components then some requirements may change they may build some other components they never go back and say Well am I running and testing until you get to the test phase.
45:01	Right so there’s that big unknown. We’re crossing our fingers when we get to that test phase. Is everything going to work right. But if you start from the beginning with the the automated tests you could have them running every day. And if someone goes and build something that impacts a previous component. Well guess what. It’s going to fail and you’re going to know about it right then and there. So is it going to take less time for someone to fix it when it’s fresh in their mind or is it going to take less time three months from now when something broke and they have to try to figure out what broke know what was the component that impacted it.
45:36	What was the expected result. What did I actually get. What do I have to fix. So you know again easy way to you know you can implement this in the organization. We offered automated test build for you testing as a service as well where you know if you prefer someone else to quit rather than you guys you know we can do it in a very cost effective manner. Definitely you know a great way to create a simple scalable auditable and repeatable process.
46:12	Right now we have this just for PBS but we’re building it for other other tool definitely reach out. We can prioritize whatever it is that you need and to build a platform like this. It’s only taken us a few weeks per application so it’s not something where we need a lot of lead time or tell you hey we need you to wait a year. For us to be able to expand this this product to what you need it for. So these are the different steps. This is creating input data.
46:41	Again looks very much like a smart view where you can enter your you know your dimensions and your rows your columns your your P.O. v defining the results is the exact same interface where you’re not you’re entering the dimensions. The only difference here is you’re typing in data values of here’s what I would expect the values to be. Whereas in the prior step here if I just jump back you’re entering the data values of what am I inputting to the system.
47:12	So here you’re saying I’m in putting this data here you’re saying in these intersections these are my expected results on a cell by cell basis. And then you build the test case where you can either do it from scratch you can select a predefined template here in case you don’t know what are the different steps that that I need to wait for you there and then once you create the test and you execute the test you can view the results.
47:42	And again they’ll be emailed to you you could go in and download it at any time here. It’s going to show you a series of tabs the first tab it’ll show you you know some some different metrics like when you ran the test. And I’ll tell you here are all the dimensions that are in your application here the user preferences of you want to make sure hey I’m running this with two decimal places or three decimal places or whatever. It’ll tell you here are the different preferences that you have.
48:15	And then a series of tabs where the first tab will be. This is what you input. This is what you said where the expected results. These were the actual results. And then on the last tab it’ll show you on a cell by cell basis did you Did you pass or did you fail so you could you could see where the failures were if there was a failure on a single cell the whole test will will fail.
48:42	So that way you don’t have to worry about getting a success message and you know there was a failure somewhere buried that that you can’t seem to find. So very simple very easy to use very easy to to hand over to somebody else to show these you know these tests pass that’s the end of the presentation my contact info is here please feel free to reach out email me.
49:11	You know obviously we’re looking to work with great organizations whether they’re Oracle customers whether they’re other Oracle implementation partners consulting firms managed services firms you know be we can add a lot of value to any of those types of organizations. We provide advisory and consulting services we manage services testing as a service we can spin up automated test cases for you have them run and report the results back to you.
49:44	We could create roadmaps do health checks of your applications and you know in terms of implementations we could do anything within the EPM suite BI suite master good management analytics and robotic process automation as well.