Download to read offline
![Panaya – brief appraisal
Strengths
• Automated listing and analysis of R11 customisations…
reduces manual effort during project planning stage
provides a robust, reliable baseline for estimation, resourcing and planning
• A comprehensive Panaya knowledge base underpins automated coding analysis
Weaknesses
• Project managing individual coding tasks is time-consuming managed on the
basis of delivery of LUW’s for UAT, and UAT sign-off
• Some custom objects were outside of Panaya’s scope at time of project:
OA Framework customisations and personalisation's [now available]
Custom Discoverer EUL objects (Folders) [now available]](https://image.slidesharecdn.com/ukougapps13presentation-final-dtnotes-151113140401-lva1-app6891/75/Panaya-UKOUG-APPS13-presentation-10-2048.jpg)
More Related Content
Similar to Panaya UKOUG APPS13 presentation
Panaya UKOUG APPS13 presentation
- 1. Guardian News &Media (GNM) Oracle E-Business Suite R12 Upgrade With Mokum & Panaya April 2013
- 2. Introductions & Background •Richard Eltham, Technical Manager, Mokum • Weeb Cnossen, Marketing Programs Director, Panaya • Binyamin Kamilar, Senior Customer Success Manager, Panaya • David Taylor, Technical Analyst, Oracle Applications Team, GNM (formerly Technical Consultant at Mokum) • Technical Team Lead on GNM’s Oracle R12 Upgrade Project • Oracle E-Business Suite Financials & HR: from R11.5.10 to R12.1.3 • Project duration: July 2012 to April 2013 • Systems Integrator: Mokum
- 3. • Largest Europeanconsultancy focusing exclusively on Oracle Applications • 150 permanent staff, serving every vertical, particularly financial services, retail, transportation, media and public sector • Completed more E-Business Suite R12 upgrades in the UK than any other consultancy • Oracle Gold Partner • UK presence, with offices in London, Manchester and Dublin • UKOUG Partner of the Year award winners since 2009 • E-Business Suite Gold Partner of the Year – 2012 and 2013
- 4. • Pioneer andMarket leader in SaaS-based ERP Upgrade and Maintenance Automation Technology • Selling globally in 50+ countries with 1,000+ customers • 2200+ successful projects (of which 200+ EBS R12 Upgrades) • Oracle Gold Partner • Advocated on oracle.com as a way to reduce the cost and risk of the R12 upgrade • UKOUG Silver Partner of the Year Award winners 2013
- 5. Why Panaya? • Inpartnership with Mokum: Panaya was part of the R12 upgrade “package” offered by Mokum to GNM • Used to identify existing customisations in R11 (11i), and to detail the R12-upgrade coding and unit-testing tasks To provide a robust, reliable baseline for the estimation, resourcing and planning of R12 upgrade technical work • Also, to identify customisations rarely used, and consider retiring them, rather than upgrading to R12
- 6. How was Panayaused at GNM? To provide a baseline for the estimation, resourcing and planning of R12 upgrade technical work To project manage the R12 coding and unit-testing tasks on an object-by-object basis, using Panaya’s project management portal
- 7. Panaya Extracts andAnalyses at GNM 1. Extracted a list of custom eBusiness objects from R11 Production instance (using Panaya extract utility) 2. Performed weekly Panaya extracts prior to, and during, the R12 upgrade project 3. Performed Panaya analyses, to provide the following: - Details of coding and unit-testing tasks to upgrade each object to R12 - Estimated effort per upgrade task - Usage statistics for “user-entry points” (custom and standard reports, forms, concurrent programs, etc.)
- 8. Using the results… 1.Identified customisation retirements, based on Panaya usage statistics and consultation with the business reduce upgrade effort 2. Grouped custom components into Logical Units of Work (by Apps module and function) – this was a “manual” process e.g. “GNMAP001_RCS_Interface” 3. Calculated sum of Panaya coding and unit-testing estimates per LUW, and added 25% effort per LUW (for admin, documentation, code installation scripts, etc.) 4. Compared total estimated technical effort with project timeline, and determined number of developers required
- 9. GNM R12 UpgradeStatistics (approx.) • 4100+ custom objects identified in R11 Production instance • 30% R11 customisations retired prior to R12 upgrade • Custom components grouped into 96 custom LUW’s (“modules”) GNMAP001_RCS_Interface GNMAP002… • Traditional Estimate: 850-1100 days • Panaya Estimated coding/unit testing effort: 300 days • Bulk of Technical upgrade work to be delivered in 10 weeks (50 days) 6 full time developers • Actual: 537 days – included CR’s, UAT rework and Post Go-Live Support Unit-tested, R12-upgraded customisations delivered on time, and on budget Overall savings relative to traditional estimate- 36%
- 10. Panaya – briefappraisal Strengths • Automated listing and analysis of R11 customisations… reduces manual effort during project planning stage provides a robust, reliable baseline for estimation, resourcing and planning • A comprehensive Panaya knowledge base underpins automated coding analysis Weaknesses • Project managing individual coding tasks is time-consuming managed on the basis of delivery of LUW’s for UAT, and UAT sign-off • Some custom objects were outside of Panaya’s scope at time of project: OA Framework customisations and personalisation's [now available] Custom Discoverer EUL objects (Folders) [now available]
- 11. Panaya case studieson Oracle.com
- 12. • An assessmentof the complexity of customer’s upgrade project based on the total number of customizations • Usage analytics to scope what can be cleansed from the system when moving to Release 12 • A project plan including the number of corrections and tests required, prioritized by the likelihood of failure in Release 12 Complementary Upgrade Analysis
- 13. Questions… Interested in alive demo? Visit Panaya - Stand #37 Visit Mokum - Stand #41
Editor's Notes
- #3 My name is… Richard and the Panaya guys asked me to give a quick overview of the use of Panaya software during the R12 upgrade project at the Guardian Newspaper. A lot has happened since we went live in April – I will try my best to remember the details! I was the Technical Lead (for Mokum) for the duration of the project. We use Oracle eBusiness for core Financials, HR and Payroll, and we were upgrading from 11.5.10 to 12.1.3. In past years the Guardian has had a relatively large in-house Oracle development team. This means the custom footprint in eBusiness R11i was large for an organisation of GNM’s size (1500 users; 2000 employees)
- #6 Why did we use Panaya for the Guardian R12 Upgrade Project? It was offered as part of the “upgrade package” offered to GNM by Mokum. Panaya software was used to automate the following… The identification of existing customisations in R11i The identification of specific coding and unit testing tasks, for compatibility with eBusiness Suite R12. The following challenges at GNM: Large custom footprint. R11i version control system not kept up-to-date. Naming conventions not always consistent. A suspicion that some customisations no longer used.
- #7 We will look at the detail of how we used Panaya in the next few slides. But, at a high level… We used Panaya’s extract and analysis tool to identify R11 customisations in the Guardian’s R11 Production instance, to provide a baseline… We didn’t make full use of Panaya’s project management portal to manage individual coding and unit testing tasks.
- #8 The logistics of how Panaya was used is as follows… Extract list of custom objects from R11i production Use automated Panaya analysis to… List coding tasks List unit testing tasks Provide estimated effort for coding and unit testing Perform weekly Panaya extracts to identify infrequently-used customisations (from usage statistics)
- #9 The data collected from Panaya extracts and analyses were used… Firstly use usage statistics to identify customisation retirements, to immediately reduce upgrade effort. Remaining custom objects grouped into logical units of work (e.g. 20 custom objects are grouped into an “invoices interface”). This is a laborious, manual process, but make life a lot easier during the course of the project! Good, existing, object naming conventions help with this process. Calculate the total effort per logical unit of work. Then add 25% effort per LUW, for documentation, installation, admin) Compare total effort with project timeline to determine number of developers required. This was our main use for Panaya. Upfront. To provide a reliable baseline for estimating, resourcing and planning of R12 upgrade technical work.
- #10 I think it was more like 1100 custom objects (tables, views, PL/SQL packages, forms, reports, etc.) 30% customisations retired Approx. 15% due to lack of use in R11 Approx. 15% due to change in business process, or use of standard R12 functionality. 850 days “Traditional estimate” this was Richard’s 300 days Panaya estimate + 25% per LUW 6 full time developers for 10 weeks (50 days) for bulk of tech work For information, an additional 237 days: change-requests, UAT rework, post go-live support. Outside of Panaya’s scope. Business process re-engineering, etc. Main point: bulk of customisations delivered on time and on budget. Quoted “Savings relative to traditional estimate” are down to these guys.
- #11 Strengths: Don’t need to use “rules-of-thumb” to estimate technical work Panaya knowledge base did miss a few coding tasks, but overall it was comprehensive. Weaknesses: Filling in completion for individual coding tasks is time-consuming. Tech work was project managed on the basis of delivering a LUW for UAT, and on UAT sign-off. Consider managing 1100 individual custom objects versus 96 LUW’s (“customisations”)