Have a Question for an ACE ? Join the Conversation

Hans Kolbe

EBS and Cloud Service Enterprise Structures Welcome and News Ascend 2022 - Conference Tuesday, 16 August 2022 1306 Hits 2 Comments

Our colleagues from Creoal present

HAVE A QUESTION FOR AN ACE?

Each month in 2022, we will be bringing Oracle Applications ACEs together for conversations with you! There is still time to register for this month's session!

The Oracle ACE program recognizes excellence in the Oracle technology and applications communities, and rewards individuals who generously share their technical knowledge and experiences. One becomes eligible by
sharing IT knowledge and experience, and by meeting official criteria. We are thrilled to share our ACE experts with you. These are the best of the best in the Oracle community.

Please join Oracle ACEs Lee Briggs, and Thomas Simkiss with special guest Oracle ACE Andrew Bohnet, Thursday, August 18th, 2022, at 1:00 PM EDT to discuss Tax.

For more information and registration use the link below

More Information and Registration

Comments 2

Hans Kolbe on Friday, 19 August 2022 21:22

Hey Thomas and Lee - thanks for the ACE to ACE discussion yesterday. I found it very interesting and congratulate you for pulling it off in spite of the main presenter (Andrew) being a no-show. I discussed the content with Seamus and a others today. Key topics of interest for me were:
1. What have you learned in the 10 years of Oracle Cloud implementations? What are you doing differently and what are you doing the same? Lee seemed to say his methodology is including more "requirements" analysis again versus initially "there is only one way".
2. What is different in your methodology and approach about implementing EBS R12 versus Cloud SAAS ? I heard that a key difference is the easier application access (no Java and VPN struggles). I would love to hear more about methodology, preparation, user satisfaction etc....

I would love for you to respond in a short blog. Also, with the Ask-Oscar.net forum we try to get controversial opinions out. So let's find those areas where may differ.

Thanks

Hans

0 Reply

Hey Thomas and Lee - thanks for the ACE to ACE discussion yesterday.  I found it very interesting and congratulate you for pulling it off in spite of the main presenter (Andrew) being a no-show.  I discussed the content with Seamus and a others today.  Key topics of interest for me were: 
1. What have you learned in the 10 years of Oracle Cloud implementations?  What are you doing differently and what are you doing the same?  Lee seemed to say his methodology is including more "requirements" analysis again versus initially "there is only one way".   
2.  What is different in your methodology and approach about implementing EBS R12 versus Cloud SAAS ? I heard that a key difference is the easier application access (no Java and VPN struggles).  I would love to hear more about methodology, preparation, user satisfaction etc....

I would love for you to respond in a short blog.  Also, with the Ask-Oscar.net forum we try to get controversial opinions out.  So let's find those areas where may differ.

Thanks

Hans

Cancel Update Comment

Guest - Thomas J. Simkiss, Jr. (website) on Tuesday, 23 August 2022 14:06

Hans,

Thanks for attending and the great questions.

What Lee and I have noticed is that the implementations have gone almost full circle. What we meant by that was:

In the beginning of ERP, when we first started, ERP was new. No one really knew what they could do or more importantly, what they wanted. So we would spend weeks, and sometimes even months, creating a requirements document, to baseline what they needed / wanted in a system. I was somewhat of a fan of that because as a consultant, it did give a clear target at which to shoot and something to measure. The drawback was, the customer didn't get to see software for a long time after the project had started.

In the early 2000s or so, Oracle came out with RapidStart (or a similar name) which offered completed setup documents and scripts to test the setups based on those documents so that the customer could get to the software sooner, but, the system may not have been as close to what they wanted.

The evolution of that approach was the Oracle Accelerators. A set of questions that looked like business questions that could be 'transformed' into setup steps to configure the application more tailored to what the customer may want, but still generic enough to get it set up quickly. It came with a really nice set of business process flows and test scripts to serve as the baseline for what the instance could do. From my perspective, this was the beginning of solutions-driven requirements gathering. Let us show you what the system can do, and then you tell us what more you want. The consultant was then not starting from a blank piece of paper, but instead was only solving for the delta.

For most of my consulting life, except for a stint with the Big Four, I have worked at boutique firms. We tend to see more projects as they are smaller and faster than what the Big Four usually see. To be certain, Lee and I worked on large, multinational, multi-pillar projects, and those projects were run very traditionally, get the requirements, then configure, etc. But for the smaller ones, we used this solution-driven approach and for the most part, it worked and still works great. Let the software, out-of-the-box, unadulterated by the burden of heavy customization show the customer the leading way to process a transaction.

I can't say when it started, but Lee and I have both seen more projects and customers want to slow down, and tell us again what they want and why then see the solution. I can say the projects where we have done that have had a better experience, albeit a more expensive one, than the customers that would not put in that time or investment.

I'd love to know what your group thinks - are the old ways better sometimes?

0 Reply

Hans,

Thanks for attending and the great questions.

What Lee and I have noticed is that the implementations have gone almost full circle.  What we meant by that was:

In the beginning :D of ERP, when we first started, ERP was new.  No one really knew what they could do or more importantly, what they wanted.   So we would spend weeks, and sometimes even months, creating a requirements document, to baseline what they needed / wanted in a system.  I was somewhat of a fan of that because as a consultant, it did give a clear target at which to shoot and something to measure.  The drawback was, the customer didn't get to see software for a long time after the project had started.

In the early 2000s or so, Oracle came out with RapidStart (or a similar name) which offered completed setup documents and scripts to test the setups based on those documents so that the customer could get to the software sooner, but, the system may not have been as close to what they wanted.

The evolution of that approach was the Oracle Accelerators.  A set of questions that looked like business questions that could be 'transformed' into setup steps to configure the application more tailored to what the customer may want, but still generic enough to get it set up quickly.   It came with a really nice set of business process flows and test scripts to serve as the baseline for what the instance could do.  From my perspective, this was the beginning of solutions-driven requirements gathering.  Let us show you what the system can do, and then you tell us what more you want.  The consultant was then not starting from a blank piece of paper, but instead was only solving for the delta.

For most of my consulting life, except for a stint with the Big Four, I have worked at boutique firms.  We tend to see more projects as they are smaller and faster than what the Big Four usually see.  To be certain, Lee and I worked on large, multinational, multi-pillar projects, and those projects were run very traditionally, get the requirements, then configure, etc.  But for the smaller ones, we used this solution-driven approach and for the most part, it worked and still works great.  Let the software, out-of-the-box, unadulterated by the burden of heavy customization show the customer the leading way to process a transaction.

I can't say when it started, but Lee and I have both seen more projects and customers want to slow down, and tell us again what they want and why then see the solution.  I can say the projects where we have done that have had a better experience, albeit a more expensive one, than the customers that would not put in that time or investment.

I'd love to know what your group thinks - are the old ways better sometimes?

Hans, Thanks for attending and the great questions. What Lee and I have noticed is that the implementations have gone almost full circle. What we meant by that was: In the beginning :D of ERP, when we first started, ERP was new. No one really knew what they could do or more importantly, what they wanted. So we would spend weeks, and sometimes even months, creating a requirements document, to baseline what they needed / wanted in a system. I was somewhat of a fan of that because as a consultant, it did give a clear target at which to shoot and something to measure. The drawback was, the customer didn't get to see software for a long time after the project had started. In the early 2000s or so, Oracle came out with RapidStart (or a similar name) which offered completed setup documents and scripts to test the setups based on those documents so that the customer could get to the software sooner, but, the system may not have been as close to what they wanted. The evolution of that approach was the Oracle Accelerators. A set of questions that looked like business questions that could be 'transformed' into setup steps to configure the application more tailored to what the customer may want, but still generic enough to get it set up quickly. It came with a really nice set of business process flows and test scripts to serve as the baseline for what the instance could do. From my perspective, this was the beginning of solutions-driven requirements gathering. Let us show you what the system can do, and then you tell us what more you want. The consultant was then not starting from a blank piece of paper, but instead was only solving for the delta. For most of my consulting life, except for a stint with the Big Four, I have worked at boutique firms. We tend to see more projects as they are smaller and faster than what the Big Four usually see. To be certain, Lee and I worked on large, multinational, multi-pillar projects, and those projects were run very traditionally, get the requirements, then configure, etc. But for the smaller ones, we used this solution-driven approach and for the most part, it worked and still works great. Let the software, out-of-the-box, unadulterated by the burden of heavy customization show the customer the leading way to process a transaction. I can't say when it started, but Lee and I have both seen more projects and customers want to slow down, and tell us again what they want and why then see the solution. I can say the projects where we have done that have had a better experience, albeit a more expensive one, than the customers that would not put in that time or investment. I'd love to know what your group thinks - are the old ways better sometimes?

Cancel Update Comment

Upcoming Events

Have a Question for an ACE ? Join the Conversation

Comments 2

About the author

Hans Kolbe

Author's recent posts