- Requirements
- Booting Up
- Inching Forward: Birth of the Service Portal
- Key features
- Key Takeaways from the Implementation
- What’s Next?
One of our customers, who is active in the medical aids sector, with more than 2.000 employees worldwide, requested our support in implementing a multi language service portal. The portal was meant to provide access for the company’s employees and some partners to services delivered by different business and tech departments within the company, in a clearly structured and centralized manner. Some examples for the services made available via the new system include a booking process for rental car reservations, or requests for the creation of marketing materials. In its current incarnation, the portal now hosts around 40 business and IT processes.
Requirements
One requirement was for the portal to become a single point of contact for contracting services within the company. The goal was to avoid multiple, heterogenous inbound request channels like individual software, email, MS Teams, Bitrix24, phone calls or the classic post-it stuck to a monitor.
The new service platform was required to be accessible by every employee both from within and from outside the company’s network, both via web browsers as well as mobile apps. While most portal users were mainly native German speakers, the portal needed to be implemented bilingually, with an English version provided for the company’s employees active in its branch offices distributed worldwide.
Other requirements included the ability to implement processes with multiple - partially automated - steps, as well as ease of use and administration by both IT and non-IT users.
Booting Up
Some stakeholders, such as external consultants, internal team leads and various team members within the company, were already familiar with Jira Service Desk. It quickly became the preferred solution, since it seemingly covered most of the aforementioned needs - at least on paper.
We were subsequently tasked with validating the initial gut feeling, that Jira Service Desk was the right tool for the job. We did this by working with pilot users; together we produced a minimal proof of concept, that demonstrated the feasibility from a technical standpoint as well as from a business perspective.
The decision to implement the new portal in Jira Service Desk was thus made and the software licenses were purchased, which cleared the way for the next phase - the implementation
Inching Forward: Birth of the Service Portal
Our consulting started with interactive, half-day process discovery workshops where we identified and selected the individual processes to be made available via the portal. The workshops were held with domain experts as well as future users from different departments. The result was a lean backlog of broadly defined processes, prioritised by business need and available alternatives.
First thoughts, brought on paper within the workshops | Implemented outcome of the demand management workflow in Jira |
In the next phase, we implemented the initial versions of the processes, in the order listed in the backlog. An instance of Jira Service Portal was then deployed in “Production” and the administrators and power users were trained on how to maintain it and to create and develop further processes.
The implementation phase was rounded up by half-day process specific training sessions for the end-users with up to 10 participants.
The current product entails
- a service portal for ITIL based IT Service and Demand Management,
- a service portal for employee services e.g. rental car reservations and procurement
- a contracting platform for internal non-IT services like creation of marketing material
Key features
At the beginning of the project some key features were already known, some others were identified in the initial phase of our consulting services. We ended up with:
- Automation of process transitions
- Enhanced workflow options
- Connection to the central user database (Active Directory)
- Various roles and permissions
- Dynamic forms
- In-house hosting
- Limited access for external service providers
- End user support for mobile devices
- Multi-language support
- Multiple sub-portals
Key Takeaways from the Implementation
On one hand, our focus for implementing the final product was to use standardized and supported software components without developing individual apps or services. On the other hand, we had to care about cost efficiency and technical performance. So for example we measured RAM usage as well as page load time after the system set up. Some ways to prevent performance issues are: try using add-ons which handle multiple features instead of installing a large amount of add-ons; do not use lots of apps that do graphical stuff e.g. rendering views or graphs; use add-ons which work asynchronously to the user input and try to not using add-ons which need to run own services.
Atlassian’s Marketplace is the ideal solution for precisely this challenge: for nearly every key feature required, a native solution existed either within Jira Service Desk’s core feature set or as an app on the Marketplace.
Our job was to identify the best matching app for the purpose. The following list shows the add-ons we selected, the reasons for choosing them and also provides some possible alternatives. It is definitely not complete, but it should provide a decent overview.
Key Feature | Selected App / Feature | Main Reasons | Alternative apps from the Marketplace |
Automation of process transitions | Automation for Jira allows to configure global or project restricted automation rules within an easy to understand rule designer. |
|
e.g. Power ScriptsTM, ScriptRunner for Jira |
Enhanced workflow options | JSU Automation Suite for Jira Workflows extends the workflow editor by multiple validations and other workflow options. |
|
e.g. Jira Workflow Toolbox, Jira Misc Workflow Extensions (JMWE) |
Connection to the central user database (Active Directory) | Jira Service Desk built-in user directories feature to connect external user directories. | - | - |
Different roles, visibility and rights | Jira Service Desk built-in permission features as well as Extension for Jira Service Desk extended project configuration for visbility settings |
|
e.g. ProForma: Forms & Custom Fields for Jira |
Dynamic forms | Extension for Jira Service Desk extends the project configuration by multiple administrative options for form handling and dynamic fields. |
|
e.g. ProForma: Forms & Custom Fields for Jira |
In-house Hosting | By running Jira Service Desk as a server licensed on-premise installation | - | - |
Limited access for external service providers | Jira Service Desk built-in feature for issue security, based on different security levels for each external service provider within the same Project | - | - |
Mobile usage for end users | Mobile for Jira Service Desk Portal comes with an own app for iOS and Android. |
|
Mobile for JSD Portal Branded |
Multi language support | Translation for Jira Service Desk extends the project configuration by a translation option. |
|
Language Translation - Jira Service Desk, Translation tool for JSD Customer Portal |
Multiple sub portals | By creating multiple Jira Service Desk projects with an own rights management and user base. | - | - |
What’s Next?
After the successful initial implementation of the minimum viable product, we started to keep a backlog of new feature requests. They include aspects like:
- Knowledge base for internal and self-service usage
- Reporting over different KPIs
- Accounting by implementing an interface to existing ERP-Software
- Domain-wide SSO via Microsoft 365
These new features will gradually be integrated into the platform mostly by the company’s own employees, which have been empowered by our training and continuous support to evolve the system themselves, thus keeping the new Service Portal alive and constantly relevant for its stakeholders.
Post header background image by Jason Goh from Pixabay.