Archive for September, 2010

R12 Patching and the Art of Zen

September 18, 2010

Reading through Wikipedia, I found an interesting article on the concepts of Zen. Now I’m not really into that type of stuff myself (each to their own), but I thought it would make an original way to present this article :-)

“One practice of Zen Buddhist’s is Koan Inquiry. A koan is a question, or statement, the meaning of which cannot be understood by rational thinking but may be accessible through intuition. The answer can occur during meditation or during your typical daily life with all the mundane tasks you do.

To Zen Buddhist’s the Koan is “the place and the time and the event where truth reveals itself”. It is a way to induce an experience of enlightenment or realization, not through rational reasoning, but through intuition.

Answering a Koan requires a student to let go of conceptual thinking and of the logical way we order the world, so that like creativity in art, the appropriate insight and response arises naturally and spontaneously in the mind.”

Or to quote from a very non-Zen perspective, you think about a problem very hard all day. You fail to make any breakthrough. During the next morning, in the shower, without even thinking of the problem, you suddenly think of the idea. Ironically perhaps we are all practicing Koan Inquiry as a natural state of mind to solve difficult problems, without even having to think about the problem at hand.

Now let’s look at ERP Patching in relation to Zen :-)  We need to be clear from the outset that this form of Zen Patching applies only to the following patches below. This is extremely important to keep in mind.

Security Patches

ATG Patches

Database Patches

This form of Zen does not apply to other ERP Patches

Applying this form of Zen Patching to any other types of patches will cause you some serious grief in your career when you report to your boss that your ERP for your entire organization worldwide is trashed because you read some amazing article by some “new age ERP guy called the Oracle Prophet” on a radical new method using the Art of Zen for ERP Patching and thought it was worth a try on your Production System……….

Do note that this form of Zen Patching does work on both R11 and R12, but not on R10. It also works on 9i, 10G and 11G databases. Please check Oracle Certification matrices and raise the question to Oracle Support if in doubt.

Oracle Support – Good morning. Can I help you?

Reader – Yes could you tell me if the Art of Zen patching is certified against R12 Apps please?

If the phone goes dead at this point, we suggest you assume Oracle Support is not aware of the Art of Zen patching and you should not pursue your question with them……….We also suggest you give your colleagues name during any telephone calls with Oracle,  in case Oracle raises a complaint for nuisance phone calls to your company…..:-)

So where does the Art of Zen fit into Oracle ERP patching?

 Let’s use a typical a koan to provide an illustration.

“We will test the patch by not testing the patch. Only then will we know that the patch has worked.”

Now at this point in time, you are probably thinking I’ve been hitting some fairly strong stuff to get to this state of mind, or I’ve completely lost the plot.

I can hear everyone thinking “So let me get this straight. You are going to test the patch by not testing the patch, so that you know the patch is working”. To which I’d reply, great you’ve got it. You are certainly a quick learner on this Zen Patching stuff!!! :-)

Our R12 Patching Philosophy actually made our auditors jaws drop, not in terms of the Zen stuff (trust me, keep this stuff between yourself and myself please and maybe better not mention to your management or auditors……), but on the thoroughness of approach.

We always have five databases for our patching (at a minimum). This is probably a lot more than most have but let me explain why and you’ll probably want to then copy this model.

Our DBA Environment. This is where the patches are applied to make sure, well they actually apply. Believe it or not some patches from Oracle don’t even apply cleanly.

Our Patch Environment. This is where they are applied with a little bit of testing. OK we deviate a little from the Zen stuff, but give me a break……This makes sure they at least do what they say on the box without major functional failure.

Our development environment, which is always busy with daily activity by our development team , functional team and testers.

Our test environment which is always busy with daily activity by our users.

Our Production environment.  I’ve been pushing our company to drop this as it uses a lot of space and we hear most of our complaints from this database, but management insist it is important and needed. :-)

We should also state our databases are pretty heavily used so application flows naturally are being used throughout development and test databases. We also apply any patches onto any other instances we have at that point in time, so that the patch is naturally tested by the simple day to day activity in as many places as possible, with a careful rollout to each environment.

 

The Art of Zen Patching

The point is simple on these types of patches. Oracle does release patches that should be applied at some point.

The Security Patches typically come quarterly and we try to apply 3-6 months after they come out. Security patches represent a serious risk to apply, although generally apply well. However security patches also represent a risk if you do not apply. You need to find the balance, but you SHOULD apply these regularly.

The ATG Patches are less frequent but provide critical updates to Browsers (especially if you have DMZ applications) and other technology components, including diagnostics.

The Database patches (and we’re talking 10G to 11G for instance) do come out periodically and at some point you need to decide to keep at least supported, although we’re very picky on applying these, but are in the process of an 11G Upgrade. (Various 10G database versions are losing or have lost premier support). This activity is every couple of years or so.

We’re not talking about applying every patch. No company in their right mind can achieve this. We’re talking about keeping your head above water and staying supportable.

The point is this. To test every time on these types of patches across every last item is impossible. The conventional way is to get the patch, apply, test everything and then move to Production in a few weeks. That’s a very logical way to order the world of Oracle ERP. But unfortunately this is not a very practical or safe way. These patches are by their very nature too broad and silently hit too many areas to be open to a logical, standardized testing process. The conventional approach actually increases risk with these types of patches because it is by no means obvious what could be impacted.

There must be a better way where you find that balance. This is the Art of R12 Zen Patching.

Our philosophy is simple. We plan carefully on all these types of patches well ahead of applying.

We do not apply these patches immediately they come out. We are kind enough to give others the opportunity to be the heroes or unenlightened who find the bugs, log them in My Oracle Support and make our life so much simpler because we heavily research each patch to find the problems the unenlightened logged. This way we avoid the bulk of the problems. Are you one of the unenlightened? If so we appreciate you finding the bugs for us, causing issues for your users on Production systems and generally making our life so much easier and less stressful.

Our philosophy then rests correctly on a peace of mind that these patches are largely stable, largely trusted and tested by others around the world. This isn’t just a philosophy, it’s backed up by hard facts based on an incredibly low failure rate of patches we have applied. The patch types listed are generally very mature, very stable and very reliable. The quality of these types of patches is far higher than the Oracle ERP patches for the application modules.

Our key philosophy can be defined by the koan below. (As you raise a smile, remember this is used in leadership teaching by guys that make more in a month than you make in 5 years and sell books by the truckload at Amazon :-)

“Once upon a time in ancient Japan, a young man was studying martial arts under a famous teacher. Every day the young man would practice in a courtyard along with the other students. One day, as the master watched, he could see that the other students were consistently interfering with the young man’s technique. Sensing the student’s frustration, the master approached the student and tapped him on the shoulder. “What is wrong?” inquired the teacher. “I cannot execute my technique and I do not understand why,” replied the student. “This is because you do not understand harmony. Please follow me,” said the master. Leaving the practice hall, the master and student walked a short distance into the woods until they came upon a stream. After standing silently beside the streambed for a few minutes, the master spoke. “Look at the water,” he instructed. “It does not slam into the rocks and stop out of frustration, but instead flows around them and continues down the stream. Become like the water and you will understand harmony.” Soon, the student learned to move and flow like the stream, and none of the other students could keep him from executing his techniques” – Timothy H. Warneka

Now I’m not into all this stuff and I’m as skeptical as anyone else, but maybe they have a point. Too many companies are simply slamming into the rocks with patches, rather than working with the flow of Oracle Corporation. Working with Oracle, you often feel that you are not talking of a stream but more a raging torrent of patches. The problem is you are always fighting against the flood of patches, rather than finding what these guys would refer to as “harmony”.

The very essence of our philosophy and the koan itself can now be answered :-)

“We will test the patch by not testing the patch. Only then will we know that the patch has worked.”

After rolling the patch through DBA and Patch environments very carefully over many weeks, we are ready to proceed to our main development and testing environments.

We typically roll patches into our development environment for a minimum of 4 weeks. We observe the behavior of the environment and record any bugs. We carefully investigate all bug occurrences.

Once we are comfortable at that point, we do run testing. OK so we broke our mantra, but nowhere near the testing that would normally be required. Why? Because we have seen the bugs naturally arise through our normal daily activity (as a Project Manager you’ll know typically what is going on and where the gaps may be I would hope). So to quote the Art of Zen,” the appropriate insight and response arises naturally.” This is the beauty of the Art of Zen Patching :-) You do your daily stuff to get to the answer of whether the patch causes major grief.

At this point we normally release the patches to our Test Instance, again allowing patches to settle for 4-8 weeks. Again using normal user activity, we gain further appropriate insight and responses, in terms of stability of the patch and subsequent bugs, arising from the natural process of user activity.

We do ask our users to test and hit the key functionality, but again, with the insight given from normal daily use, we have achieved ” the appropriate insight and response which arises naturally” as a Zen Master or Leadership or Lifestyle coach would tell you for quite a lot of cash :-)

Even our DBA Team reaches a relaxed Zen like state and if you know your average DBA guys……… With planning comes time for our DBA Team to work and document carefully the steps needed for each patch. The timeframes create space for many, many practice runs, so that on the day of application to Production, they know exactly what to do and what to expect. It also creates the space and time for good old fashioned research on My Oracle Support. (A tip is that as we’re doing this approach over a number of months, the DBA’s always get copies of Production on a regular basis to run through the patching process, so any production specific issues are always encountered early).

In addition, we carefully plan for releases. So if you take our last security patches, these were rolled into an ATG RUP6 and a minor database point release (to stay supported). This reduces a constant patch cycle to a more manageable ITIL Release concept, reducing your workload overall. The raging torrent of patches becomes a much more manageable stream.

Most companies have huge stress over these types of patches. Most companies don’t even bother applying, much to the detriment in terms of support, future upgrades and security.

We are like every other company in many respects. We are highly conservative on applying patches. We like to stick on what we know.

But we do pay attention and plan for security, de-support of databases, new browser support in ATG RUP’s, etc in a very careful manner well ahead of time, allowing us to practice the Art of Zen Patching :-)

Companies stress out, rush patches and therefore make mistakes. That is not the Art of Zen Patching. Zen Patching stresses the very opposite approach. Put the patch into your environments, slowly observe and watch over many months, then test and finally you will see the appropriate insight and responses that it has worked. Now looking at Wiki again, Monks meditate over many months or even years to answer a Koan. There is no difference in the approach of Zen Patching :-)  The time the patches spend in your environments can be thought of as your meditation period over many months (typically 3-6 months depending on risk assessment) to find the answer to the koan of “how to test the patch without testing the patch to know the patch has worked”.

But with our R12 Zen Patching, we’ve reached an almost Zen like state :-)  Patches are simply a natural part of the lifecycle of ERP. We have accepted that. They are planned and are allowed to settle for several months, to give insight into their nature and risk. Patches still require testing, but to a far lesser extent than a fully focused, high risk “lets test this patch and apply this patch in two weeks time”, which is similar to slamming into the rocks in the stream.

So where are we today with such an approach?

R12.0.4 RUP5 (yes this was a nightmare of testing the old fashioned way, definitely slamming into the rocks in the stream, but our go-live was incredibly smooth. Zen Patching doesn’t work here I’m afraid for those embarking on an R12 Upgrade. It’s the good old fashioned conventional testing approach that is needed here).

Security Patches to April 2010

ATG RUP6

11G and July Security Patches are currently under the Zen method as is a SUSE Linux Upgrade

We have never had a failure or serious outage as a result of Zen Patching (should I trademark this perhaps and make a lot of cash like those leadership guys??????), although as with all Oracle patches, it is a very serious business, with serious risks, so there is no place for complacency.

So what about the opinions of others on our ERP and how up to date we are overall with patches?  To quote one Senior Consultant DBA recently, we are way ahead of most companies in terms of patching, and have an “aggressive patching policy”.

I would say that the Art of Zen Patching can never be described with words like “aggressive” :-) . In fact it is quite the opposite. It is a very slow and considered process, stressing great patience, over many months, waiting for insight as a part of a natural process to reduce the risks we face, as the real Zen guys would put it :-)

We simply achieve a lot more than most companies, with a lot less effort and a lot less risk. I think the Zen guys and leadership/lifestyle gurus would term it as “simply learning to move and flow with the Oracle stream creating harmony and peace of mind”. Obviously they’d be charging a thousand US Bucks an hour for this type of advice. (I remember we had one such IT Guru in our company. Cost us 6 figures for six weeks of work – we ended up using his laminated b*llshit as coffee mats……that was about the only value we got……). Now maybe the Consultant our company hired wasn’t too hot except for the coffee mats, but with some of these leadership and other philosophies, well maybe there’s something in it after all……

Call it Zen. Call it Lifestyle (or is it Patch) Management :-) , but to have a safe, low risk and stress free approach to this type of patching which works with reduced effort (rather than increased effort) is  not a bad place to be, as an ERP Manager…….

Health Warning

This article was designed to present a very serious subject in a hopefully entertaining and educational manner utilizing both conventional approaches of testing, in conjunction with a more unconventional approach. However applying any patches on a Production Database is a very serious business. Patches do need testing and this should never be underestimated. However the point of this article is that by allowing patches to settle into various instances over time, you vastly increase the chances of spotting serious issues and vastly reduce the risk of issues in production that conventional testing can never address. This is the safest way to apply such patches that I have found, using a conventional testing approach, together with a far less conventional approach. 21st Century Testing meets 5th Century Zen Philosophy.

Disclaimer

(By the way, I haven’t been smoking anything….the intention of this article is to present a very serious subject – Oracle Patching – in hopefully what some will find a very funny and original manner, that can then be remembered and applied to help all of us that face the very serious risks of patching global ERP Systems, so don’ take all the Zen references for Patching too seriously………otherwise someone may think you’ve been smoking something………). Think Monty Python British humour as you read it……..

If you remember the article, change patching from a rush to a planned perspective and patch carefully over a period of months, then the article did it’s job :-)

I hope you find it as funny to read as I did writing it :-)

Related Articles

Tags:, , , , , , , , , ,
Posted in ERP Management | 9 Comments »

An iRecruitment Odyssey

September 13, 2010

 Too many companies do recruitment in a not dissimilar way that would probably have happened around the time that Homer wrote his famous Odyssey poem back in 850 BC. Exaggeration – maybe a little, but consider someone needs a person, they advertise, interview and the person gets a job. Want another person, repeat the same process. That’s the way it happened three thousand years ago and it’s still largely unchanged today for too many companies.

Now the 20th century has added some refinement to the recruitment process, but it still left an awful lot to be desired. Your average organization still posts into newspapers or into the (almost) 21st century job boards on the internet. Your average applicant will have a nice shiny resume to send.  Your average organization will still process the same loser that you’ve rejected twenty times on each application. In short, recruitment still remains for most companies, a very intensive process indeed with many non-value added processes involved.

Our organization was somewhere between 850BC and the 21st Century in terms of recruitment, although probably leaning to the former rather than the latter…….

This led to some pretty serious problems for our organization:

  1. Recruitment cycles were incredibly slow
  2. Adverts cost a lot and don’t really hit the correct audience most of the time
  3. Good candidates were lost for future positions as it was all paper based. There was no corporate memory of candidates
  4. There was no option of pro-active recruitment, unless you looked through millions of papers in filing cabinets
  5. By the time you get the process going, the candidate is not available
  6. Candidates rarely find your organization, unless they read the right newspaper on the right day – recruitment is not a process, it’s a chance encounter between the applicant and the organizations advert
  7. Processing large volumes of candidates was slow and time-consuming as the HR department was swamped by job seekers
  8. After going through 200 resumes, you work out that 90% of those are not even relevant, but you still need to check every resume just in case………
  9. For staff away from the office, it was difficult to apply as paper submissions were required

In 2008, our organization decided something had to give. We were in major expansion mode needing considerably more staff (around 20%), but our recruitment processes could simply not support the business need. The case for iRecruitment was born and the odyssey began.

Our project followed the typical standard AIM lifecycle model, with the usual BR.100 Setup documents, MD.050 Functional Designs, etc.

 

We won’t dwell on the lifecycle model as its standard Oracle AIM. But what we did find was that for an average iRecruitment implementation, it could be achieved in 6-9 months, giving a pretty fast win and an even faster ROI.

Pre iRecruitment, our recruitment process was pretty archaic (and probably familiar to way too many readers…….)

  1. HR writes a job specification
  2. HR asks web developers to post job specification on organization website (and many don’t even have this today…..)
  3. Web developers enter this into the website
  4. Contact the newspaper with the specific advert, even though you have no idea if the adverts actually get you candidates or if it’s just a waste of your dollars or yen or euro……..
  5. Applicant views jobs either from website or by chance in the newspaper
  6. Applicant downloads a form from our website
  7. Applicant fills in form
  8. Applicant emails form to our organization’s HR Department
  9. HR Department files form in a very large room with millions of other forms – if you remember the scene from Indian Jones when they put the Ark of the Covenant in a huge warehouse never to be seen again. That’s kind of what happens to a lot of job applications……
  10. HR Department types form details into Oracle HRMS – the form is hugely complex and we needed teams of people to do this. Even more interesting was that only a fraction of the details were ever recorded and many details were wrong……….
  11. HR Department reviews each applicant
  12. HR retrieves forms from filing cabinet for shortlisted candidates
  13. Shortlisted candidates are kept in an Excel Spreadsheet
  14. Unsuccessful candidates aren’t told anything as processing 100 rejections would take too long. The impact here is that candidates think your organization doesn’t really care, so they won’t bother applying again
  15. HR prints short-listed candidate forms and sends to relevant department through internal mail
  16. Department Co-coordinator gets forms one week later
  17. Department Co-coordinator sends forms to relevant person one week later…….
  18. Person reviews forms, writes comments manually and gives back to Department Co-coordinator
  19. Department Co-coordinator sends forms back to HR department, where they manually update the comments into HRMS (sometimes……)
  20. HR arranges interviews with the person (if by this time they are still available)
  21. Department wonders what is going on as this process can take weeks
  22. Department finally gets all the forms back in triplicate for applicant interview
  23. All the other applicants are wondering what is going on as nobody informs them of progress of vacancy
  24. Interview takes place – notes are all paper based
  25. End User Department informs HR of the results
  26. HR validates the results
  27. HR send offer to candidate (via email)
  28. Candidate accepts or rejects
  29. All details are then typed fully into Oracle HRMS
  30. If someone wanted to find the same skills in the future, the process either had to be repeated or someone had to look through millions of pieces of paper or someone had to remember that two years ago they saw a really good resume…….not exactly a good process…….more a recruitment lottery than process.

This was a long and extremely painful process for the Applicants, the HR Department and the End User Departments requiring the resource.

By bringing in iRecruitment there was a very radical shift, both in terms of process, but also in terms of the mindset of everyone involved.

 

With the new process 100% online, we reduced the overall process by more than 50%…..

  1. HR writes the job spec and presses a button to enable on the website
  2. Applicants fill out their own details online, directly into HRMS
  3. HR reviews the applicants online and presses a button to refer to the End User Departments
  4. End User Department shortlists online, with full visibility to the HR Department
  5. HR arranges the interviews, with candidate automatically informed of status of either interview or rejection with regrets at all times during the process
  6. End User Department interviews
  7. HR validates results online
  8. HR Department sends the offer
  9. HR Department changes the Person Type in HRMS to Employee with no other changes required

10.  It’s a wrap!!!!!

The advantages of this process are very obvious indeed:

  1. Immediate savings by removing the need for a team of people to type in potentially 60,000+ resumes per year, with all the mistakes that entails
  2. Electronically link your advert to either your website or job sites, all under the control of your HR Department
  3. Removal of over 1 Million pieces of paper per year – good for the planet and good for your business
  4. Candidates are kept in the loop at all times and this shows your organization in an extremely positive light
  5. Reduces the need for expensive newspaper adverts
  6. End User Departments have far quicker access to Candidates
  7. Reduces the recruitment cycle time significantly, giving you the edge in recruiting the best people
  8. Massive online, searchable resource database that allows pro-active recruitment
  9. Reduces significantly the amount of HR time spent on recruitment
  10. Online referrals
  11. Apply anywhere, anytime and attract candidates GLOBALLY
  12. Hugely flexible model can be applied to centralize the HR process and federate the recruitment process

The biggest challenges and pitfalls we faced were on the Change Management and some issues very much specific to putting Oracle ERP into the outside world:

  1. The Technical Team (DBA Group) had to become very familiar with the DMZ Configuration to allow iRecruitment (and effectively therefore your ERP) to be put into the big, bad internet world.
  2.  Keeping up to date in terms of security patches in Oracle ERP is key. A prime example of a security flaw reported can be found on the following link.
  3. Keeping up with the latest ATG (Technology Patches) is critical, as you are now moving from your nice “my company has these PC’s with this Windows version” to “any candidate with any device (PC, Apple Mac, Ipad, etc) running any O/S with any browser wants to use your site”. The only manageable way to do address this major technology issue is to let Oracle Corporation do it for you: watch Steven Chan’s column, watch My Oracle Support and make sure you keep reasonably up to date on ATG Patches. Plan carefully as some of these patches are massive and although generally very good with limited impacts to your ERP, care as always with Oracle patches is mandatory. 
  4. The concept of a support team for external users was not really there – although iRecruitment saves a huge amount of resources, someone still has to answer the user calls. A solid user support structure must be in place and it’s a real grey area whether this is an IT or Business Responsibility. Our HR Department took the lead in this. Supporting a massive global user community is very different from internal support. 
  5. Our biggest User Support problems were related to:
    1.  Character Sets (make sure you have a multi-byte character set on the database, otherwise cut and paste from Word, etc fails……..This will cause support chaos and I am sure some companies are still running without multi-byte character sets)
    2. Login issues (Make sure you have very clear Quick Guides)
    3. Browser issues (make sure you are on the latest ATG Patches and keep updated)
    4. General User errors (good User Guides are essential)
  6. What was actually most difficult about this process was really getting the HR Department to let go of non-value added functions. This required a huge amount of Change Management effort and even 9 months on we are still not there. Letting go of functions that have been performed for the last 40 years is understandably very difficult, even when they add no value (and actually detract value from the process). 
  7. The other aspect of iRecruitment is again on Change Management. It really is a revolution to go from passive recruitment (wait for people to apply) to suddenly having a massive database of resumes that you can actively search on. This hasn’t really quite hit home yet in terms of changing mindsets within our HR area. Suddenly they have a resource pool of 40,000+ applicants, 2,500 staff and 20,000+ Consultants available to search at their fingertips with highly advanced resume search capabilities. 
  8. Customizations were required which ideally would have been better avoided. However the iRecruitment module is pretty flexible in this respect.

What we also found is that there is a wealth of companies out there using iRecruitment. We learned a lot simply by trying some of the sites and looking at their Help Guides. You never know, I may even get a new job with one of the registrations :-)

However as the statistics show, the rollout of iRecruitment has been a huge success, with a massive and very active user base.

iRecruitment Statistics
Months Live Applicants Database Growth Per Month Vacancies Applicants Per Vacancy Successful Recruitment Paper Saved Process Reduction
9 Months 45,000 5,000 700 73 241 1M+ Sheets 50%

 What is amazing is the real global reach of systems like iRecruitment. A quick look at our statistics shows applicants from 85 countries from countries across Europe, the US, Asia and Africa. Countries as diverse as Philippines, Japan, Canada, Australia, Italy, Vietnam, Mongolia, Afghanistan, Tonga,  Russia, Iraq, Jamaica, Peru and South Africa to name but a few.

Great talent is in every culture, race, religion and every corner of the planet. iRecruitment allows you to very effectively tap into that huge wealth of human talent, wherever it may be.

All of the above of course can lead to some interesting support issues that you will not generally encounter in your average day to day support of internal Oracle ERP systems.

Of course we’re not there yet. So what does our future hold in terms of iRecruitment?

  1. Upgrade of the database to support documents in Microsoft 2007. This support comes with 11G and above.
  2. Questionnaires to filter out the 90% of unsuitable applicants so that resumes don’t even have to be reviewed. A sample is shown below.

 

3. Skills and Competencies – a very advanced feature that will allow you to match Job Specification skills and competencies to that of the candidate (including both internal and external resources)

4. Rollout to 28 countries worldwide to support our other offices across the globe (happening in September 2010)

5. At some point upgrading to 12.1.3 or above to take advantage of the extensive interview functionality available.

6. Finally persuading the HR Department to let go of the short-listing and let candidate details go straight through to the End User Department, to allow our HR personnel to move from low value added activities to pro-active recruitment

7. Assess Oracle Business Intelligence iRecruitment, to allow our HR personnel to move from low value added activities to analysis and improvement of the process worldwide

 

 Looking back, our iRecruitment project certainly had some fairly unique challenges, given this was dealing with a very large outside user base. However, overall our iRecruitment Odyssey was a short journey, relatively painless and low-cost with huge rewards at the end.

This was definitely a journey worth undertaking.

Other Resources

There are a huge amount of resources on the Web that is interesting for any company implementing iRecruitment. My thanks go to the generous authors and organizations that make these resources available to all.

For those with Oracle Open World On Demand access, the following may be of interest from 2009:

v  End to End Talent Acquisition in Oracle iRecruitment 12.1

v  How to achieve High Volume Recruiting with iRecruitment

Tags:, , , , , , ,
Posted in HRMS | 8 Comments »

Tools for a Recession – JIRA

September 1, 2010

Not exactly an optimistic title, but companies have been tightening their belts and asking for ERP Teams to do more with less. Further a lot of companies that use Oracle ERP aren’t the mega rich companies but small to medium sized businesses, so getting tools to help you with your job in ERP isn’t easy.

However there is a whole parallel universe to all your expensive, fancy vendor tools. In this article we’ll look at one company that created an incredibly useful, stable and very flexible support tool.

Now I know what you’re thinking. This is crazy running these non-fancy, inexpensive, unsupportable, high risk tools in large companies. I had a colleague who was always ranting about these tools and how open-source would take over the world. I regarded that colleague as a bit mad to be honest. However, I’m now eating my words and am totally converted and writing a blog “ranting about these tools”. Interesting turn-around………….

These tools are heavily supported. These tools have become main-stream. And these tools do provide amazing functionality. In short, any organization should have a look at these tools as they vastly improve your processes, your ERP Management and at the end of the day, improve your customer service massively.

The Tool for a Recession Product for today is called JIRA. It is ridiculously cheap and for some organizations free:

“JIRA is free for use by official non-profit organisations and charities (proof of non-profit status is required). There are certain organisations whose purpose is to make the world a better place, and we believe in helping them achieve that.”

These guys not only write great software, they also have a very positive, highly ethical and pro-active approach to helping all organizations that aim to, as they so eloquently put it, make the world a better place.

JIRA is from a company called Atlassian. The website can be found at:

JIRA Website

This website gives a very comprehensive view of the functionality, which is way beyond this articles remit.

This article is purely intended to tell you what has worked for me in managing Oracle ERP including Support and Projects (although this tool could be used for pretty much any software development or change management).

So what do we use it for?

Change Management

Our Change Management process for ERP Requests used to involve lots of paper requests from our users and a large spreadsheet. Not exactly rocket science and a huge pain to manage. Things got lost, forgotten, etc. We used this manual process to manage around 20 modules in our Oracle ERP.

We are now managing over 40 modules (including custom) in ERP, so it is fortunate we put a more automated process in place using JIRA.

With the capabilities we saw in JIRA, we figured that we could get the signed copy of the Change Request, create a Change Request in JIRA and then attach the signed Change Request. This allowed us to have lots of other information held on our Change Request, such as Impact, Risk, Department, Module, Sub-module, Audit References,  etc which proves extremely useful. Actually we found that JIRA can be easily extendable (with no programming) to include a very large number of fields.

Issues can further be categorized to pretty much whatever you want – Bugs, Improvements, Patch, TAR (Sorry, Service Request – I am showing my age…), etc. A sample fully customized Change Request Screen (with no programming) is below.

We are working to remove the paper completely by allowing users to directly enter the Change Requests, get Approval from their managers and simply assign to our IT Group. This not only gives a super efficient support process (with visibility to all) but also removes completely all paper trails, but provides a vastly superior audit trail over any manual, paper based system. (It also allows collection of statistics on your processes, allowing for further process improvement, as a simple by-product of using the tool).

One of the great things about JIRA is that it has highly configurable workflows, so we mapped our ITIL Processes onto JIRA, allowing us to track where a Change Request was in the process at any point in time.

I won’t go into detail on the workflow, but basically it is totally configurable with no programming and very powerful indeed, with of course e-mail notifications, etc.

An ITIL Change Management Process was put in place so that each person in the IT Team updates their Change Request statuses as they progress.

From a Manager viewpoint, it is then very simple to assess the workload of each person, module, etc and where each request is in the overall Change Management Lifecycle.

From a Management viewpoint it’s also pretty interesting to watch the stats. A lot of Cancelled Change Requests shows a tendency for a department to ask for trivial items that are not needed. Similarly disapproved indicates a further tendency for trivial and unnecessary changes. Too many in Team Lead review suggests perhaps your Team Leads are swamped. The Summary views can also be seen by module, by developer, etc. Actually as the backend of JIRA can be Oracle, you can pull out virtually any statistics that you wish. Additionally JIRA has easy extracts of the data to Excel, making Management reporting a breeze. Key statistics such as Aging are easily available.

A Management Dashboard can be easily configured to give pretty much any view of your Project or Support for ongoing ERP Operations. JIRA has so many gadgets that can be added showing different windows in a dashboard with great configurable filters.

 

 So adding for instance a gadget called Two Dimensional Filter Statistics can give you an exact view of all the tasks, statuses, etc of your entire team on a project, on a dashboard in real-time, at your finger-tips instantly. (Which is faster than you could say that sentence……)

(The names have been airbrushed so as not to embarrass my staff who have lots of backlog requests to do on Oracle ERP……Hence the names look messier than they would in JIRA)

One of the other interesting aspects of JIRA is that it tends to create a real community, as developers can fix items and assign to testing, then testers can put screenshots and other attachments and notes of what is failing. It tends to really increase team interaction tremendously, resulting in faster projects, less cost and better products overall to the client.

Finally JIRA has good security allowing the right information to be accessed only by those authorized to do so. We’ve found it to be pretty flexible.

I’ll be posting an ITIL compliant Change Management process in a future blog for those that are interested (that has been heavily scrutinized by the likes of Deloitte and PWC, so I guess it’s reasonable). It’s not super complex, just enough to get you by the auditors.

 

Bug Tracking and Management

The other area that we use JIRA for is Bug Tracking. Given a lot of people will be doing R12 Upgrades I thought the best way to show this would be to actually show a few screenshots of our R12 project itself and how it is setup in JIRA.

We setup R12 as a new project in JIRA. This keeps it simple

As we moved through the project we had different phases/instances of R12 (shown below) modeled as Versions in JIRA terminology:

If you have a look at the R12 articles elsewhere on the Blog, you’ll start to see how this all ties together. We started out with our R12IMP (a very early release) and then moved to a more stable R12 Development.

We spawned off various testing environments (R12UP4, R12UP5, R12UP6, R12UP7) as we went through a horrific number of patches (this was 2008 and R12 wasn’t stable back then).

We finally moved into R12UA1 (our internal testing – IT Group) and R12UA2 (External Testing – User Group).

Finally you can see our R12CUT. This recorded all bugs during cutover to Production on 3rd August 2009, making sure that everything was recorded (we cloned PRD to R12CUT after upgrading PRD and tested on the clone before the users got onto PRD) and all bugs fixed. This was done over a four day window. Not an easy task, but JIRA certainly helped hugely in that process. We went live with no major issues.

So going back to the bugs, JIRA again made it incredibly easy for us on the R12. Bugs were logged by QA’s, developers, Functional guys, etc. These were then assigned to the appropriate resource to resolve, then re-assigned to test, then closed. Service Requests could be tracked (as JIRA can add additional fields) as can Patches. This gave a complete view of the entire R12 Project in terms of health and overall bugs. A detailed view is shown below (that of course has drill downs). As with just about everything else in JIRA, the views are also highly configurable.

During testing, Developers or QA’s or Functional guys could also take a quick screenshot and attach to the bug, change request, etc.

The great thing is that as we went through our Versions (effectively stages in your project or environments depending on what you prefer), JIRA can be modelled to track each and every stage.  So if you apply for example a patch in a new instance, you can retest and track all the bugs associated with that particular patch on that particular version. (Configuration takes a few minutes in JIRA to allow this).

As well as Versions (Phases of Project or Environments) we also modelled each module as a component in JIRA. This allowed an easy and quick view of progress, bugs, etc across our R12 ERP Suite.

Again this gives easy access to Team Leads, Functional and Management to see problem areas, before they become problem areas…….

And hopefully at the end of your R12 Upgrade you’ll have a screen of lovely green in JIRA, with minimal issues left as you go-live. Our final status report in JIRA shows completion across all environments and phases, with no major issues outstanding.

 

Summary

The important take-away from this blog is that JIRA provides great Change Management and Bug Tracking (ideal for R12 projects or indeed any IT project).

Of course, we suggest you also go and have a look at the JIRA website on

JIRA Website

as there is so much more to JIRA than we covered here.

A truly remarkable piece of software.

Tags:, , , , ,
Posted in ERP Tools | 2 Comments »

Follow

Get every new post delivered to your Inbox.

Join 28 other followers