OpenText / StreamServe
Concept: Provide a tour operator with a new system for customer communication.
The goal of the project was to generate travel documents - airplain and train tickets, hotel reservations, information brochures etc. and distribute these documents to the customer - via email (Part I) and via post (Part II).
We developed a project in the following directions: reduce the cost compared to competitor's system; transfere responsibility for system maintenance from IT staff to customer support staff; minimize development cycle of the customer communication documents
Project Scope
Before my team started the project implementation, multiple meetings between the customer side and my colleagues from pre-sales took place, to ensure that the declared functionality of the product met the requirements of the customer.
The work had to be carried out in the following steps:
- Installation and configuration of programs and deployment of infrastructure on the customer's servers (two environments - dev and prod, using Windows operating system and Microsoft SQL each )
- The visual design of the documents
- Setting up a text store and rules for the automated customer interaction
- Educate customer support stuff on system usage and maintenance
- Get ready for the second part of the project - generating the printed media
Lessons Learned:
As it was the first big enterprise project I participated in - I could gather some useful input for my future career.
- One of the important aspects was the usage of waterfall model for project management and planing. This setup lead to classical problems including too long iteration, lack of timely feedback and not meeting the deadline.
- Also I could observe some consulting specific problems like the not sufficiently trained stuff and overselling. The money paid for consulting does not guarantee results when the consultant does not have the time and opportunity to work into the new system.
- During the pre-sales demo, one tend to sell more comfort than they could actually provide and overestimate the technical skills of the customer service employees.
- Some minor issues included the lack of automated testing and version control system.
The rather conservative management structure on the project lead to an interesting phenomenon, there were too many responsible departments and a lot of micromanagement overhead. Up to 2/3 of the project, there was no dedicated person responsible for the entire project, which was critical considering the number of project participants and contractors. What I learned is that it is very difficult to explain to the customer the difference between visualization and technical realization. It's easy enough to create a document that looks like it's 80 percent complete. It is very difficult to find the level of abstraction that will be understood by all parties.
What is intuitive and understandable for one category of specialists may not be intuitive for the other. Misunderstanding does not indicate a low degree of skill sets. The seminar for consultants helped me understand, the dangers of being biased towards clients who do not have the same level of technical training.
An interesting aspect - was to get rid of the legacy system, and to solve tasks that were considered unsolvable. We were lucky to avoid the classical problem - that the new system should copy the old one. It was an interesting task from an analytical and communication point of view.
With different management structure the project could have been implemented with less time money, effort and stress. When too many different departments of the company are involved, when each department of the company reports on the piece of work - but in the absence of interaction between departments and integration of the completed parts - every single result is useless. Lack of coordination is as bad as not completing a task on time, and completing a subtask on time, does not guarantee the success of your project.
What are travel documents?
When a person or a company books a trip or hotel - the travel documents are issued - including a flight tickets, a hotel voucher, occasionally transfer documents for a trip from the airport to the hotel or train tickets.
The user receives a full set of documents through one of the selected channels - Email or mail. The user is also provided with information about the legal requirements in the country of arrival, data on vaccination and medical insurance, as well as information about the culture and customs of the country, such as the working hours of restaurants, the amount of the tip or the crime situation.
StreamServe systems cover exactly these demands - generating documents from structured data (e.g. XML) and distributing documents to end users through the specified channels.
If the documents were not generated correctly or the end user has questions, the support service should have access to the already sent documents, as well as be able to correct the error or resend the documents. And just as it was already mentioned above, the cycle of development and implementation of new documents should have been minimized.
The documents themselves were generated depending on some factors, such as the type of trip, the country, the scope of services, the chosen language for the documents, as well as the brand under which the reservation was made. Since it was a large tourist conglomerate, the parent concern included several brands whose documents differed in type and volume of information.
Project walk through
The first thing to do was to configure the necessary infrastructure for generating and sending documents via email (email body and attachments). All document types but one - train tickets generated by Deutsche Bahn IT and retrieved directly from FTP Server - were generated by StreamServe directly.
- Different brands
- Huge amount of personalized texts
- Minimized development cycle of documents
The documents themselves were made in StreamServe Story Teller, a WYSIWYG editor that works with XML data (at least at that time). The texts were stored and processed in a web application called Content Center.
The work was carried out simultaneously in two directions - a requirement analysis of all cases was made from the customer support point of view. We needed to achieve an understanding on how the data is visualized on travel documents and what data structure adjustments are required. I have worked closely with customer support employees and therefore was able to establish a semi-iterative process.
In parallel, we are working with texts - the legacy system for text maintenance was written in the COBOL language. Since we were talking about a legacy system, the data was stored in a data structure - with numerous if statements - and each statement represented one rule to locate the text. If it was necessary to change or expand the rule by which the text was displayed, very often a new query branch was simply added, and the text was duplicated. As the result, the number of rules was five times higher than the number of unique texts.
The first task was to consolidate all the rules and texts. Secondly, we had to transform the rules from a colloquial form, into rules that followed the Boolean logic to correspond with SQL statements on a DB level.
The Content Center provided the ability to create rules using a less technical pseudo language, the Low Code System. I have observed this pattern in other projects as well - I find this approach very counterintuitive. An abstract pseudo language is generally conceived as simple and intuitive, but ceases to be so very quickly due to the complexity of the systems for which it is developed. And in place of the promised simplicity, we get queries that are not inferior in complexity to native queries written in SQL, but at the same time we get an additional application layer that is also prone to programming errors.
After the technical problems were solved, most of the work was occupied by teaching employees on a customers side how to use the system.