Tools for a Recession – JIRA

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.

Advertisements

Tags: , , , , ,

2 Responses to “Tools for a Recession – JIRA”

  1. Bill Yarberry Says:

    Great blog article. We are looking to replace Incident Monitor, which has been the software equivalent of a “failed state.” [maybe that’s too harsh — it works but is awkward and time consuming] We will definitely be looking into Jira, based on your comments. Regards, Bill Yarberry

    • irroberts Says:

      Thanks. Very much appreciate the kind words.

      Of course I’m not saying that larger, more expensive ITIL (Incident, Problem, etc) don’t have their place. But certainly there are many great Open Source products that also may be ideal for smaller/medium sized companies, not wanting to spend too much cash in these difficult times.

      I wish you well in your endevors to get to a good Helpdesk system – it’s a key part of any good IT department.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: