IntegratiON episode 05: Discussing Jira integrations with Anna Odrynska
Anna is a Chief Strategy Officer at Alpha Serve — Atlassian Platinum Partner, ServiceNow Technology Partner, and Zendesk Tech Alliance Partner.
Anna is based in Kyiv, Ukraine.
How is the situation now? How are you?
Living in the war is complicated, and sometimes exhausting. The days differ, one can be calm, and one not. Work is something that really helps, to stay concentrated, even alive. We never stopped operations at Alpha Serve, even though we have a significant part of the team here, in Kyiv. We needed to relocate people from our other office in Mykolayiv since it was completely destroyed. We adapted to the situation.
We have two developers, who decided to join the military and protect us.
The motivating part is that the war happens only here, in Ukraine. Everyone else in the ecosystem continues to do business, they go ahead. If we would stop working, all our past achievements would be neglected. Our friends, who joined the military, even asked us to continue doing what we were doing, to try to live a normal life. But sometimes, it’s hard. Especially emotionally.
Please tell us a little about Alpha Serve.
Our core expertise is BI connectors for professional software. F.e. Power BI connector for Jira, or Power BI connector for ServiceNow. In short, it’s connecting professional collaboration software with professional business analytics. We provide customers with user-friendly, easy-to-use integration tools, not to spend time on complicated development and setup, but rather on business analytics.
Alpha Serve is in the integrations business too, your apps are available on various platforms. When integrating two platforms, one needs to understand the differences between them. It’s often hard to do exact one-to-one integration. It usually requires some preparations. How do you talk about this to your clients?
The approach we have is generally the same, as Getint. One difference is that we don’t integrate similar collaboration software tools like Jira and Azure DevOps, so technically it’s a bit less complex. In our world, the main work to be done is on the business side. To prepare for the integration, the company needs to know what are their reporting requests, what is their business process, and where and how the information can be found exactly. They also need to know the data model of Jira, to know what kind of information they can get. You need to make sure that the final report will provide the answers you’re looking for, so you would be able to make some decisions based on it.
So when our customers are preparing for the integration they ask questions about:
- How to set up the application,
- Whether are there any additional costs,
- What is the form of payment,
- How many data sources can they use,
- Whether are there any limits or premium features,
- Where the data are stored?
- Who has access to the data?
- Do we collect something?
- What is support available?
- What is the reliability of a Vendor (what customers are you working for, what reviews do you have)?
- …and the most common question from Atlassian customers is … “I have like 1,000 people in my Jira, and I have only 5 business analysts. Do I have to pay for all the users?”. The answer is always yes, those are the rules of Atlassian.
Some customers are also concerned about data safety, and data security.
Integrations are business critical. To make them work a company needs to prepare internally, prepare processes and data, and train the people. The switch from one Vendor to another is costly and has a direct impact on business operations.
When choosing a Vendor, companies want to make sure they work with a reliable Partner. To be sure, several years from now the application will still be supported.
Jacek: It’s very similar in our case, to collaboration software tools. The process of setting up the tool is easy. The challenging part is understanding the organization, what are the goals, what date the company wants to integrate, and preparing the tools.
Anna: Right. What is also similar in our cases is that when you select a ready solution developed by a third party, the scope of the project is simpler. There is no need to support it, it’s done by a Vendor. You don’t need to write up the docs, a Vendor covers it. So the main challenge for the company is to understand the process, configure the app and that’s it. All the rest is the Vendor’s work (support, bug fixing, improvements) — that’s what you pay for. When you develop an integration internally, which some companies do, the project scope is more complicated. It has to include not only the development part, but also the support, documentation, release plan, training plan, a process of adding more features according to constantly changing business requirements, and so on.
We have customers that started the internal project of developing an integration internally, but after facing plenty of bottlenecks they come to us anyway. They start to realize that the most important resources they have are the soft skills of the people, and it’s much more valuable to let them focus on their work than to develop some kind of solution that is not their core business.
“The main idea of developing integration tools is to let people focus on delivering what’s giving the biggest value for the core business, not to distract them from developing the tools themselves. Do not spend 80% of your time on technical development and setup, and just 20% of your time on the work itself. The core value is to allow businesses to focus on their business operations, and let integration software do the rest for you”.
Another thing to consider is when you will be able to start benefiting from the integration. If you want to do it internally, you need to plan it, develop it, test it, implement it, and so on. With a ready solution, you can start almost immediately. For some businesses that is the main factor to get a tool. Who runs quicker… quicker gets the results. So if we have two companies, one developing the tool internally and the other getting a ready-to-go solution, the second one will get the benefits now.
You post a lot of content on your blog. I once saw an interesting comparison of the ITSM tools. Can you compare ServiceNow, Jira, and Zendesk? What’s best when? How do teams use them?
The customers are really different. ServiceNow is much more complicated, it’s harder to implement it when compared to Jira ServiceDesk or Zendesk. Those are the enterprises with thousands of people, and complicated processes, that need to have everything documented. They are usually operating quite slowly. The big plus of ServiceNow is that it can be customized however you need it.
We start to see that bigger and bigger companies are choosing to use Jira ServiceDesk, so this competition will be exciting to watch. Jira and Zendesk are much easier to use, to start working with, which is a great value for the smaller teams that don’t have very complicated and documented processes. When it comes to Zendesk, what makes them different is that they have the CRM. So if the CRM is the heart of the business, it makes more sense for a given team to use Zendesk.
Companies need to think in the long run. While selecting the tool it’s not only a case of solving some issue now but to choose a solution that will be supporting your cases for many years to come. Define the main processes that you want to digitalize, and optimize with software. Is it customer service, support, development, or project management? Decide on the main process first, and then try to estimate which other processes you would need to add, and then decide which tools to choose.
Think about the complexity, and uniqueness of your internal process. The more unique, and complicated the processes, the more customization is needed. That means additional cost and time.
Lastly, think about other software that needs to be integrated with the software. Are the integrations possible, and in place? The compatibility of the software is important. The stronger the ecosystem the better.
Migrating the data — what should we be aware of?
The main point is to find the differences between the tools and find a way for them to align those differences, to make sure you can transfer everything you need. And there is a place for it in a new system. Consider the internal processes. Migration is a moment for reflection on the possibility to stop doing something or start doing something. Prepare yourself well, to make sure the quality of the data migrated will be as expected.
In short, testing, preparation, and backup are the best advice.
When choosing the Vendor, what should a client take into consideration?
The first thing is to make sure the product does what you need.
If that’s checked, the next step is to decide on the right Contractor.
We asked our customers, what do you take into consideration when choosing a company to work with?
- Product documentation. Clear, understandable, readable, structured documentation. Oftentimes, a person selecting the tool needs to also train others within the company. Without proper documentation, it’s much harder to do it.
- Support. If there is support provided if there is a place to turn to when facing issues.
- How quickly will you get the answer, and will you get it?
- Does the Vendor provide live demonstrations?
- Is it possible to schedule a live demonstration with all the interested parties within an organization, to let them ask the questions they have?
- Reviews. To understand what kind of problems people usually have, and how they are solved.
- Security. Each Marketplace has special programs for Vendors to participate in, so they check if the Vendor complies. If they do, it’s a first green flag.
- How often are the releases happening? To make sure, the product is supported, and improvements are made. That relates to the reliability part.
- Website, and blog posting
- Social Media, and the frequency of posting
- Rarely, but sometimes companies are also checking the media presence. What do people say about the company, who is the management, and what are the employee’s reviews?
- Being transparent, and visible.
the post was originally published at getint.io blog; https://getint.io/integration-interviews-e05-discussing-jira-integrations-with-anna-odrynska/