Introduction

Some opensource apps are old, and with rapid technology development, we all hoped that some new great apps would evolve. But the reality is that the 'good old apps' I used more than 8 years ago are still here, and they are still a reasonable choice for several tasks. The key to implementing a business app in a corporate environment, from my viewpoint, is not in the app itself, but in the business process around it.

So, in this article I'll cover two 'apps of choice' for me, which I used several times:

• Dokuwiki, a wiki
• Mantis, a bug tracker

They are both written in PHP (oh, my...), but they are both still alive. So, the use cases for these apps are:

1. A knowledge database using a wiki, I had 3 of these
2. A task management system using a bug tracker
3. A claims management system using a bug tracker

A knowledge base using wiki

The requirements are quite simple: make knowledge inside a consulting company available to the staff, because when you stop 'reinventing the wheel' on every project it costs less and involves fewer risks. I saw a knowledge database that failed because of access issues. If you want maximum leverage of the knowledge, you have to make it a priority to maximize the usage:

• Make the knowledge accessible to everyone
• Make it easy to contribute for everyone

It becomes a complicated issue in a big company, and I didn't have this problem in my case. If you are restricting access, I'd consider two questions:

• Is this information so valuable and easily applicable to other companies?
• If someone wants to steal this information, are there easier ways to do that?

Ok, that was a preface, the real work starts with building the business processes around the knowledge base. What are they? I prefer to keep things simple, so I start with the two processes:

• Input, or collecting the knowledge
• Output, or using the knowledge

Again, if you want to maximize the leverage of the work accomplished (and the knowledge you have), then 'can' turns into 'should': we should connect the knowledge from particular phases and we should use it first when we are looking for the solution on other projects.

You could have separate processes for that, but the easiest way is to get current processes and instead include this Input and Output as procedures in particular places. Thus it's a change and it requires less effort to implement.

What's different about these 'knowledge database-related' processes and procedures is that people get excited about collecting useful knowledge for the team. So making a 'top contributors' list is a good idea to encourage them.

A task management system using a bug tracker

Every organization has a kind of workflow and task management tasks that fall outside the scope of specific systems like ERP (enterprise resource management systems). Now we have BPM (business process management) systems, that allow us to construct almost any kind of process, and further automate some of the functions inside the process. The question is: can this be simplified? I tried to simplify this, and it worked, and the main idea is the following.

What if we say that we won't construct a process out of any fantasies, but instead use a template: someone starts an action, it should be approved, assigned, executed, and controlled. It could be different, but it should be something similar. And we could have several templates, but let's just get the idea with one. It works as simple as that for 90-95% of cases, then why should you pay more?

If you can fit the majority of your processes, then... welcome to the world of bug trackers! You do not need a BPMN system, you could have issues, issue statuses, and comments (with some attachments), which is dead simple and deadly effective.

What modifications of the bug tracker are required for that? Well, none, as the names of the statuses can be changed. What you need to do is to agree on the status sequence and develop a business process model to use these statuses. Here's an example:

1. Someone raises (creates) an issue
2. Some boss approves the execution
3. An issue is assigned (or picked up)
4. When an executor reports that the issue is done, the issue can be closed OR
5. An issue is checked by someone else and closed

Mantis is one of the simplest systems. What's important: first, it's stable and it works and, second, it allows to have a kind of forum/discussion for each issue with file attachments. This history of issue execution was vitally important for the business.

A claims management system using a bug tracker

A claims management system has several differences from the workflow described above:

• It's initiated by the customer
• Customers and client managers are usually not very specific about the issue, i.e. they do not provide enough information at once
• Issue execution (an investigation) usually gets stuck at some point and needs a push from someone, but the bosses are too busy, right?

Having an issue number and an SLA (Service Level Agreement) regarding issue resolution are highly valued by the clients. The first is provided by any bug tracker. What I like about Mantis, is that it has an overview with the 'latest activity' timestamp, so the SLA can be controlled and an issue can be escalated. But we have several questions still:

• Who should ensure that the issue is described fully enough to start the execution? Otherwise, the system and the process will be overwhelmed with issues missing some important information.
• Who will ensure, that issues do not get stuck? And, by the way, those issues are closed, which also cleans the list of issues for everyone.

That's simple: you need someone for that. We called that person 'a claims engineer' and she wasn't subordinate to anyone participating in the process. She could reply 'you need to provide more information' to the client's managers and she could escalate issues, that were stuck. And it just worked.

It seems a bit more complicated process, but the fact is that even Mantis allowed us to implement this process without any modifications, just using the statuses. But with a business process model, a procedure description and a proper training for everyone involved, of course.

We had a few ideas to develop this further:

• We could conduct a periodical analysis to enhance the processes, that lead to claims
• We could investigate, who was in charge of the consequences and provide feedback for that person (sorry for the 'managerial' language here, I hope you got the idea)

On the tech side, we could download the statistics from the Mantis database, build some reporting, and make some conclusions. The structure of the database allows you to do that, because... it's dead simple as well.

Conclusions

I prefer the lean approach, and the simplest solutions work cost-effectively. What I love about bug tracker systems, is that they got through a long evolution, and they are feature-rich, stable, scalable, and nice to work with. At first, they can be a bit awkward to use for 'business' people (yes, the 'managers'), but no one could ever raise any particular issue about that. An old-fashioned interface? Well, it works. Not too much AJAX? Fortunately, 'business' people don't know these words. Everyone was quite happy about those systems and I hope they are still in place.