I have noticed a lot of posts on social media talking about JDE security and the need to redesign your security as part of an upgrade process. There's lots of advice dispensed about what needs to happen to make this process work more effectively and to encourage you that the results you will achieve are worth the monumental effort involved.
While most of the advice is good, I believe that it doesn’t go far enough, and is too narrowly focused on the IT aspects of security. Security in JDE is a way to facilitate the business users access in the system, while keeping the company data and assets safe. Although security has typically been the domain of IT, it really should be owned by the business and administered by IT.
It is true, many companies try to avoid a major security overhaul. They may see this effort as disruptive, costly and without any clear benefits or because they believe that if what they had in place for the old system was good enough, then it should be good enough for the new system, or they believe that it would be too complex. This is typically the response when IT has initiated the security project due to technical issues or concerns. When driven from an IT perspective, the process can be very disruptive for the business, and the business will tend to resist, ending up with exactly what was feared. When IT is initiating a security project, it is always advisable to involve the business early on. The same is true when the business initiates a security project, IT needs to be involved early on. In both cases. take the time to explain how a security project will benefit the company, add to the bottom line, and make life easier for everyone. Get IT and business buy in and participation to make the project go smoothly and to truly deliver value to the business and IT.
We’ve all heard the adage “If it ain’t broke, don’t fix it!” The problem with that saying is that with JDE security, you may not know that it’s broken. How do you find out if a major overhaul of security is called for, or if there is no need for it? Before you decide to go down the path of a full-blown security project (with your business users’ full involvement), you need to have an independent assessment of your existing security setup performed. The security assessment should provide a solid understanding of where you are today, where you want to go, and what it will take to get there. What are the tangible benefits and how can they make a positive impact on the business and IT? If there is not a real business benefit, the likelihood of any change is significantly reduced. Every situation is different, from the modules in use, compliance requirements, and volume of changes, to changes in personnel or business requirements.
There are many areas that need to be reviewed and analyzed as part of a security assessment. In addition to the areas you expect to be reviewed like application, action, and row security, you need to be sure to include Task Views (this is the original JDE UX One), compliance (even for private companies), your user and security provisioning processes, and most importantly business requirements. Don’t forget about the business users’ experiences with all these areas as well as any ongoing concerns or issues along with new system functionality, including usage of some of the newer JDE security capabilities.
The security assessment should accurately identify areas that need improvement along with areas that are doing well. For areas that need improvement, the analysis should explain why, in plain English, and provide recommendations on how to make improvements. In many cases, a security project can be broken down into smaller mini-projects to allow you to demonstrate the efficacy of the new approach, or to address the most critical vulnerabilities immediately and buy time to do a full project properly. Be sure that you don’t get sidetracked and have commitments from everyone involved to keep the project as a priority to completion.