We will eventually describe how each of the helix's above represent a continuous project, either reducing technical debt (or making updates easier) and the other enhancing how we use JD Edwards.
Why improve continuously?
I think it's well known that focus on iterative improvement (if you can) will reveal better results with small costs and impact of change. We you are improving continuously, you can train people continuously (a smaller group), you can measure and quantify the improvements that you are seeing and you get better and better at implementing improvements.
When we talk of improvements, this is simply making end users jobs easier and more efficient. We do this in 100's of different ways and the JDE toolset allows us to enable much of this efficiency with UDO's or their very flexible development environment - what I'd call a more traditional SDLC - Software Development Life Cycle. At present, we see that man efficiencies are coming from automation, and the adoption of it's bigger brother - enterprise automation. In it's essence, the foundation of automation is integration.
Continuous improvement is also baked into the platform. Though JDE is not SaaS, the ideals of customer paced "SaaS" is a JD Edwards release ideal. If you have efficiencies in how you can apply the updates, then you can have all of the benefits of SaaS without the sting in the tail.
What's the SaaS sting?
The sting in the tail of SaaS is commitment… You are committed, there are no more platform decisions… If you adapt the solution for you, there is cost to maintain your customisations over an every changing platform - of which you have NO say in cadence of change or what is going to change. Some might say that SaaS is great for standard businesses with standard approaches - but buyer beware - everything is subject to change. The other factor of SaaS is pricing, when you are committed there are not many button and levers for reducing your pricing. The perpetual license allowed you some flex in costs. If your business was struggling you could choose not to pay maintenance and sweat your IT investments - ahhh - NO LONGER on SaaS. You cannot sweat anything.
I quite often think that SaaS feels nice and new and shiny… I need to be honest with you, I do not like looking after servers and internet connections - it's not good for my blood pressure. But, my ideal place is JD Edwards in public cloud… I can update continuously when I want. I don't look after tin. I'm secure and I can implement the most amazing cloud services to create native data lakes (eg. Our fast start JDE -> S3 data lake accelerator) - with minimal investments.
SaaS is not going away, because it’s great for large software vendors - talk about lock in… Easy to buy, easy to login… hard to leave.
Why in integration so important to everything?
Integration is no longer an afterthought, it's a first class citizen in design ideals. No new software platform is released without a complete integration solution. These are generally API based when needed, perhaps push / pull when required and also batch.
This is an important point, new SaaS subscriptions or any new software needs integration as a first class tenant. You need to be able to report over the data and reconcile the data - you also need to make it part of your master data strategy and understand it's place in a transaction timeline. You probably want to ensure that it can connect to your enterprise reporting suite natively too.
Guess what, JDE has a very mature approach to all these integration patterns. We have RTE (Real Time Events) for pushing data. We have orchestration's for implementing the VERY important "dumb pipes / smart end points" for integrations - APIs etc. We have type 3 & 4 JDBC drivers and rest based (loose) connectivity to the tables. Finally the good ol' UBE for batch. Nice. We also complement this with antiquated BSSV [please stop] and EDI. Pretty neat. Choose the right tool for the right job.
From <https://docs.oracle.com/en/applications/jd-edwards/interoperability/9.2.x/eotin/jd-edwards-enterpriseone-interoperability.html#u30175980>
Integration is crucial because we are seeing the rise of the "best of breed" digital adoption. Point solutions are deployed in seconds, finely tuned for their purpose and can integrate natively. I'm seeing more of my clients choose point solutions, all cloud based, and making sure that when implemented they respect master data and security ideals. Oh yes - this is a huge reason for a strategic approach to integration. Remember that your enterprise security posture is generally only as strong as the weakest link.
Integration enables automation. Integration reduces human error. Integration speeds up business. Simple.
Summary of above
Of course I'm a JDE guy, so you might consider the above with a grain of salt, but what I'm getting to is JDE is an amazing platform with a written guaranteed roadmap until 2034 and rolling year on year. It's ready for all integration patterns, you can host it on any hyperscaler and you can do process improvement at your pace. All good…
Now, finally, what do I mean by Double Helix approach to continuous improvement?
The two stands of the helix represent 2 concurrent ideals / projects for JDE. Imagine that the blue line is modification reduction, or technical debt reduction and the second (red) is continuous improvement.
This is a duplicitous parallel stream that JD Edwards customers should dedicate resource to. At times you may only focus on technical debt reduction and other times you might focus on process improvement, but they should work hand in hand. For those of you who do not have a blue strand (you are without modification), then you can run a single helix.
Time is the X axis and effort is the Y axis, so you see that you can continually put effort into either stream, knowing that BOTH are contributing to lowering the TCO for JDE and also improving efficiencies in your enterprise.
Process Improvement
The types of projects that make up continuous improvement are:
• User productivity improvement
○ UI / UDO adoption
§ E1 Pages
§ UX One
§ Search Groups
§ Cafe1
§ Manage Queries
§ Oneview reporting
§ Form personalisation
§ Notifications
§ Form extensionsJDE maturity model
§ WatchLists
§ Workflow modeler
§ Form Extensions
§ Logic Extensions
○ Enterprise automation
○ Speed and efficiency
○ Maturity model assessments
○ Alert -> Analyse -> Act
○ ERP Insights & JDE usage analysis
○ Implementing AI / ML
• Integration
○ IoT
○ Process
○ Data
Process improvement is important, but more importantly is quantification of benefits. You cannot quantify the improvements in productivity without a baseline, which is why we recommend our customers use ERP Insights to understand their JDE usage and use this data to baseline, measure and therefore quantify the productivity improvements in JDE. All process improvement should make users jobs easier, reduce errors and processing time and allow users to do value add tasks.
The Alert -> Analyze ->Act paradigm helps us determine where the value add can occur. We want to implement as much alerting as possible… This means that the ERP is telling us about problems. Instead of checking the bottom of 1000 page integrity every month, get notifications of exceptions… The nice thing about simple alerts is that with enterprise automation we can covert these into workflows / integrations for self-healing… Acting on an alert can be an easy automation… Instead of the notification we just mentioned, we might add a journal automatically with an orchestration or an adjustment to balance our accounts due to rounding errors - all with thresholds and reporting.
The nice thing about doing the above is that it could be a citizen developer doing all of this. There is not package build or deploy - all of that automation above is done by an power user. Your user base can spend more time of the analyse part of their jobs, which is proactive - value add… Doing things that algorithms and models cannot do.
My recommendation is to use a service like the Fusion5 maturity model, which will put some laser focus on your usage of JD Edwards. We probably want to you have ERP Insights installed first. We'll look at your system usage under the microscope for that module and make recommendations for process improvement and enhance your use of Alert -> Analyse -> Act. We'll find the best places for enterprise automation and recommend the lightest touch to implement the chance. All of which is going to improve your usage of the module, improve your usage of JDE enhancements -> which assists you in all other modules.
Technical Debt Reduction
The types of projects that assist with technical debt reduction are:
• Removal of modifications
• Adoption of Mobile
• License analysis
• Automated testing
• Archive Data
I'll put a slightly different slant on this, I want you to read technical debt reduction as "how can I make upgrades faster"? Everyone understands that the variable component of an upgrade is retrofit - nearly everything else is predictable. So, we need to remove or reduce the impact of retrofit, which is done with technical debt reduction.
It's been said over and over that strategic modifications can stay - no problems. Bolt on modules are pretty easy to upgrade too, the overhead is knowledge & testing - not too much technical retrofit of modifications. Changes to core objects though, they need to be kept to a minimum.
Here is a story that I have been told 50 times… Let's to out upgrade "as is", we need to do it quickly and go live… Okay, I say - we carry forward all of the technical debt at this point in time. We hardly do analysis on the modification, whether it has been superseded by existing functionality. Is there a smarter way of doing the code (with UDO) or is there a smarter way of implementing the process with deep functional knowledge? It's too hard with the pressure of the upgrade project looming… There is not enough time and it’s hard to estimate.
What if you did all of this work up front? Whether it was module by module or object by object - have a continuous technical debt reduction project running. Removing modifications, changing processing options… making upgrades (updates) easier… Then, when you get to your update - you'll be surprised by the efficiency. Remember that UDOs are not your only options for modifications. You need to think about the improvements with orchestration and the ability to use modern mobile platforms to deploy your JDE functionality. JD Edwards can be overwhelming for users that are not logging in all of the time. Replacing this with a simple mobile app (insert favourite mobile app deployment software here) using SSO via JWT to ensure that your data and logic is safe. The security model being enforced by JDE and therefore orchestration studio ensures that you are implementing least privilege principles over your valuable ERP data. You also know that is just going to work after you take release 24 - because of your loose coupling implemented as part of your JDE SDLC.
You know that oracle tests their software extremely well before it gets shipped, so you know that the standard functionality is going to be working. You need to test the standard code as it applies to your business. You need to ensure that your loosely coupled UDOs continue to work and you can start being smug about keeping JDE up to date on a yearly basis - efficiently and predictably.
You might then start looking at automated regression testing and data archival to speed up some of your other painful go-live activities.
No comments:
Post a Comment