Change Management

Following the suggestion from Per Bay (Forum: Open Subject / “How many are REAL Programmers?”). I’d like to come back to a discussion we already have had in March but unfortunately never had come to a solution. So let me start it again: what is Change Management (CM) CM covers of two issues:

  • Version management and
  • documentation
    I think I’m not the only developer who made the experience that he had to document the same function in two or three different places: [list]- Within the object,
  • within the developer documentation,
    within the customer documentation[/*] The first target for CM therefore has to be to reduce the documentation-work for the programmer, give him a tool to automate the process of collecting documentation which belong together (= same version), create a report with all changes. Search for changes etc. Since february we are working in our NSC on a CM solution. Let me introduce our ideas and then tell me what you think about and what we could make better: CM is - of course - a Navision add-on. It’s main connection to standard Navision is the project. The project table has been enhanced to contain a Version Symbol (Such as IBM) Connected to this version are Change-headers and Change-Lines. The Change-headers are uniquely identified by the version number. Line 1: IBM01-01 Line 2: IBM01-02 Line 3: IBM01-03 etc. The change also contains starting date, developer, keywords, references to external WinWord and Excel documents and the project. The version numbers in the example above (e.g. IBM01-03) match of course to the version numbers used to document the changed object, the version list and the filename: IBM01-03.FOB. So far you might have used version numbers with dots like IBM01.03 but we decided for the dash instead as you cannot use a dot within a file name. IBM01-03.fob is a valid filename while IBM01.03.fob asks for trouble. The Change-Lines are defined by the Version-Number and by the ID of the Changed object. Example: Line 1: IBM01-03, Table, 50062 Line 2: IBM01-03, Form,50070 Line 3: IBM01-03, Codeunit, 80 Line 4: IBM01-03, Codeunit, 50000 Each line also contains text lines which contain the documentation. The documentation is being generated out of the objects which have to be saved as text files. Live examples: Early morning, programmer gets a new Job to do some modifications for customer IBM. He starts the CM, creates a new CM record which assigns him the next new version number 01-04 (thus: IBM01-04) This Version is now reserved for him and he will comment all his changes with this number. For every object he touches he adds the documentation to the DOCUMENTATION header. Such as:

07.07.01/NSC/myname - here comes description
bla bla bla bla

He also changes the version number of the object in the Objekct designer to IBM01-04. Three days later he has done all modifications (he touched 9 objects) and has all documented. He exports the modifications as IBM01-04.FOB and as IBM01-04.TXT. He starts CM again, points to the record IBM01-04 and starts a function which will read/parse IBM01-04.TXT and generate Change-Lines for him. Each of the 9 generated Change-Lines will contain the object type, object number and the documentation text. He can now start a report which generates a IBM01-04.html containing all his changes. We usually send this IBM01-04.html together with IBM01-04.FOB to the customer. — End of example Navision DK recommended to version each object individually. (Which means you increment a version number for each object). Doing so you might do a change 01-20 in Table 37 and a change 01-03 in codeunit 80 the same day. We believe that this method is not suiteable to track changes efficiently. Instead, a version number should be issued by programmer and by topic. The version number changes if another programmer does changes or if the fob has been installed at the customers db. Like in the example, the programmer in question will use the same version number for all changes he does for this customer during three days. Additional features within the change management tool provide search functions, reports by customer/date/developer and the like. Ok, now tell me what you think about it. ------- With best regards from Switzerland Marcus Fabian

This sounds excelent. In fact, it is similar to a add-on I wrote for my company. However, since mind was written as an end-user add-on, my process starts when a user requests the change. A user has a button on the main menu. This starts a new request including a new version number (like you sugested by subject). The request goes through several status until completed. All objects to the request can then be tied together. It also updates Outlook with new tasks and has a place for “attaching” documentation. So, it seems after all very similar. Other ideas? Bill Benefiel Manager of Information Systems Overhead Door Company (317) 842-7444 ext 117

We have since version. NF2.00 used an own created tool for making a new version of changed object. It’s real simple. You just enter version code (Company code) and next version number. For example: CMP1.27. We are also saving the version in a table and changed object in a second table. That will give us tracking of witch object was changed in witch version. We are storing all or external documentation in Lotus Notes in a case handling system. A “system update document” (don’t know right term in English) will be written with changes done in the version at the same time we are doing the development. We will also have links to the case and test protocol from the document. Product Manager

You are spot on. I have used just a system like this, though it was not in Navision but Concorde (Damgaard) XAL. I am sure the guys from Columbus IT will know what I mean. This idea can be expanded just a little bit by having comments on the change-header and short descriptions on the change-lines, date fields etc. etc. Moreover when you need to export certain functionality to a customer (make a build or release) you can filter by change-header and get the export to contain only the objects in the change-lines (without repetition). And so on and so forth. It would be THE best thing for developers on serious projects. If I ran a development team, I would pitch for management to buy such a tool if I could not make it inhouse.

Marcus : Any plan in releasing your Change Management add-on in the download area ? I need a good tracking tool, I’ve got zillions of thing to keep track of and my (LIMITED!) brain has just reach saturation level :wink: So I’m really on the lookout for a little piece of software which can help … I once wrote something similar for a NSC I used to work for, unfortunatly I’ve been honest (or stupid?! I wrote it over 3 week ends) enough to not take the FOB on a floppy with me when I said goodbye to them, and I really don’t feel rewritting the entire thing from scratch … Can someone rescue me ? ######

Hi all, any news about this ‘Change Management add-on’ ?? I’m VERY interested in this tool.

Hi, I would be interested in contributing to the development of such a tool. I have often mulled over whether it would be worth my time creating a change management system, and my former employers regularly brought up the need for better cm processes (without doing anything about it of course!) I sorta envisaged something that would integrate with jobs and timesheets, with perhaps a billing function, a solution that could be adapted for both NSC’s or by end user sites. Anways, if anyone is interested in collaborating on such a thing, feel free to email me at and we could try and work something out. If there is a publicly available system out there already, I would be interested in finding out more about it! Regards, Edward.

As I see it, then it’s not really a matter of “just” change management, but as responsible for a large global Navision implementation, it’s more change request management including error fixing. Internally we developed something we call “Development Issue List” where all change requests to our global core solution is registered. And then we use this tool to manage the request from idea, analysis, design, development, test to release including setup etc. We actually have a very advanced tool that also allow us to attach documents, manage version lists, projects and team members. With this and our internal development methodology (descriping how to document changes in the development database, then we are actually close to what we see as an ideal solution. Our remaining open issues are to find a better way to manage tests and release plans (incl. automatic updates of version lists).