So go ahead.
Thank you. Good afternoon. My name is Renee and I've been working for he sauna for about three years. And I'd like to tell you a few things about one of my current projects, which comes with me almost the whole health honor time. It's about the migration of an over 12 years old IM system, which did not fulfill all our current and upcoming requirements to a new and modern solution, which solves tax actual issues we have and provide a reliable pace for the future. Furthermore, I'd like to show you our lessons learned we had so far first, I'll give you a brief overview about the company and the project to give you some background
Sauna was founded over 100 years ago with the name. Let me think. Veia sorry. And they merge together in 1990 with Artisana to the new company named he owner. Actually we have an income from six to 5 billion Swiss Franks 70% is of health insurance, which Isians Switzerland and 30 per person supplement Terry insurance, which you can choose on your own private insurance or whatever. He sauna pays out a week over 110 million Swiss, Franks to hospitals and doctors and so on. So you see why we need the money.
Sauna has over 3000 employees and ensures more than one to 9 million Swiss people. In other words, every fourth human in Switzerland is customer of health sauna. Therefore health sauna maintains a lot of offices in Switzerland to be close to its customers and to provide services locally in the main location, state park pretty close to Zurich are more than 50% of all employees working enough about that. Let's start with the migration project. What was the solution and which approach did we choose to, to migrate from Microfocus net IQ to sale point identity IQ.
I show you a few numbers about our system. These numbers are actuals. They are more or less the same as before the migration and shall give you a bit an overview about the complexity and size of our IM system. Currently we have about 4,000 internal and external identities and 3,600 technical identities. I guess you all know what that means. So the organization roles, we have 3000 organizational roles and they are fully managed by sale point identity out IQ automatically based on an input file from HR. So there is no effort required from our people to manage them. Business and technical roles are managed manually by our internal role management team. Technical roles are orderable only manually. They are never be assigned by our rule business rules can be assigned by our rules automatically or ordered manually. As you can see, we only provision 35 systems that seems less, but it isn't as the active directory and is also one of them. And with that, we provision over 200 applications at the end. You can also see we have 44 reports. That is not, seems not to be much, but this means it means custom reports. They are developed individually for us and are additionally to the base base report of the systems.
What was the situation before we start with the project in 2016, we had Microfocus net type Q running for a long time. Product productive launch was in 2005. The system is pretty complex and to fulfill our requirements and concerning performance and audit demands, seven productive servers are needed to fulfill these. And this is only in productive environment. Net IQ brought an upgrade to the market and we thought we need to have that as well as they improved a lot of things, which we were, which we want to have and to put in place. But we figured out that new version is almost a new product that, and it would cause a lot of effort to implement the software. And as we did customize our software very much far away from standard, it would also cause a lot of testing issues, testing efforts, and what issues result of this. We didn't know. So at this point I came into play and we discussed the possibilities. We have. I sat together with the product owner and principle and we discussed the possibilities and thought it would be, we could change that bad situation to a good thing and evaluate the market. If there are better solutions available now, I mean the software was up and running for 11, 12 years. And then we really decided let's start an evaluation project and see what we can do better. Maybe.
So Julie go. So as you can see, the, the project timeline we built seems quite long, but, and we figured out that it isn't really a project. Even we have a start date and an end date, and it is hopefully unique for a long time, but it, we figured out it's more like a journey than a simple project. I'll get to back to this slide later. I would like to tell you now, what did we learn? So far technique is important, but I believe two other points are more important to be successful with such migration project. The first one is project execute, project definition and its goals. And the second one is project execution itself. And I don't say this because I'm a project manager and not a technician in such such a complex environment. You have really to focus on what you need and not on what you like would like to have, therefore be clear what you want and especially what you really need. Product brochures are quite interesting. They list many cool features and you will realize you can't live without them anymore. But is this really true? I doubt in my opinion, it's really crucial to ask for everything you want. Do I, or better the company really need that. And if you can honestly answer the question with, yes, you should ask yourself again, do I need that? Or the company just now, or can it be done implemented later in a second phase? In the third phase,
I know health owner was like this. Most probably a lot of other companies are the same. Yes, we need that. Then we need that now. But from my point of view, this is dangerous. It's the best way to overcome a project and to fail in consequence of this, to prevent this, we hired an external subject matter SME as subject matter expert SME. From the very beginning of the project, we spent a lot of time showing him what we are doing, what our current pain points are, our new requirements. And so on with that knowledge, he did also support us in creating RFP, RFP and the definition of the pork. He also helped us analyzing the offers we got and to take a good decision afterwards, for each requirement we put, or we said, we need that. And he, if he didn't accept it, he had a clear, clear explanation why it's not the right thing for us or why it doesn't need to be done right now. So with that approach, we could keep the project scope pretty clear and manageable during all project phases. He also reviewed all concepts from our implementation partner, check the validity, challenge them in implement implementation effort. They estimated and signed off all concepts in the first place
To hire that SME causes also a little problem for he on of course you need a very experienced person to, to take over that position else. It would be waste of money, but because the strict rule, because our strict rule that the company of the SME can't offer for the implementation project itself, we reduce the potential implementation partner by one, one company, as you may know, Switzerland is not that big. And as we sent out the a fees we noticed that was really a good company to offer, but we are not allowed based on our, our own rules to send them the RFI. Nevertheless, having an SME on board is great to success at, to ensure project success. And I can really recommend that approach, execute the project in several manageable phases and don't underestimate the time the project needs. I show you the timeline again, as you can see, we start in late 26, 16 with the RFI RFP POC process. It took us almost one year to find an implementation partner and to sign a contract with them where we had lazy. No, of course not. But as I described before, just to find the, the ideal candidate as a SME that takes some time to educate him, that takes some time.
Then you send out the RFI that also takes some time because that potential partners, you sent the RFI, they are not waiting in the office and, and for receiving and answering RFIs, they are all always pretty bit pretty busy and in my feeling always understaffed. So from my point of view, you have two options in that situation, put pressure on the, on the timeline, but you will get only 80% of the answer. If you get one at all or let them enough time. So you receive reliable answers, which you can compare it to, to other offers you receive or answers to run the POC. We decided to organize a kind of contest between the two best candidates from our, after our RFP. We also agreed to pay them for the time they spend on our P I tell you later why, but you can imagine if you want to have two companies for two weeks in your office at the same time, that takes also some lead time. So time is flying by, and one year is almost nothing to get there. And as a last point, I repeat myself and I recommend, recommend to scope the project accordingly and split it in different phases. What, in our case worked pretty well. We run the project with an evaluation phase, which I just, this mentioned afterwards, a migration phase to move from the old end user Porwal to the new one from sale point. And now we are in the third phase of the project where we move at the net IQ drivers from to provision the system to the new sale point connectors.
We could scope and schedule each of these three phases, very clear what helped a lot to keep the project risks and project impact low, and to report the project status to management and upper management accordingly, I guess you still think it's, it's long having four years for a project like that. And I say it is, but keep also in mind that you need a lot of internal knowhow to, to run such a migration JML processes operating of the system reports, interface, connectors, I guess your internal guy are all also as busy as they are in his sauna. So no. So even if you are able to hire an implementation partner who would show up with 15 FTEs, I learned you won't be able to answer all the questions they need to implement the system at your needs. And, and at the end, you can't keep the implementation partner busy. We made pretty good experience in having a rather small project team from the implementation partner at Sana. A benefit of that is also that each member from the implementation partner has a very good understanding of how health sauna is working and how they need on or how they need to implement the system and processes to satisfy us,
Leave space for the unpredictable don't under underestimate the dependencies of such a project. I think it's in the nature of such a product to be somehow important and central for a company useful. It's connected to all company relevant systems. If you run a project for three or four years, the world is still turning further. You will be confronted with new business requirements, maybe new HR processes or something else, new applications, driver, or connector updates, commissioning for old applications and so on. Therefore don't plan too tight leave space and distinguish between a lapse time and effort.
Interestingly, sorry, project communication and marketing. This is also, this is something we underestimated the importance. Interestingly, I don't mean don't mean communication and marketing to end users. Guess we all know that that this is important and we are all doing it. I talk about communication to management and upper management. It's not easy for them to understand why the project should last another one and the whole fear of the go life. It's important to make them clear that the end user part was just the whole front of the project. You need to make them understandable, understandable that there's still a lot of work to do in the backend. Even they use the, the software already in their daily business. It's also difficult to make them understandable that such project has interfaces to all other relevant systems and they can't decide to update other systems and applications without involving you leaving time space in your planning helps you to fulfill other requests without getting delayed with your project or causing a huge effort for change management and all discussion discussions around it. What is more important who has to pay what, who has priority? And so on
Project project execution, product evaluation, take your time to choose the right product. Great sentence. I know, but what I mean by that is the following. We talked about features and scoping already, but there are so many applications on the market, which you may be evaluate. I personally was completely surprised how, how many applications is available for that. And each one has its own pros and cons. Of course, some of them are need a cloud connection. For instance, we were absolutely not aware of this. Our system was running for 12 years on, of course this is only a on-prem product. So what the heck? Why should that be in the cloud? And so we had a lot of discussions held on internal just to find out if we would be able to use a cloud product or not. Also, they big difference from in this product area is the operating model. Some of them are need a lot of server. For instance, as our old one, there's seven server for production, huge amount also to maintain it is this important for you to, to have a small system or you don't care if you need 20 servers, this also something you need to think in advance,
Partner evaluation, as you can see on our, our project, it's a long term relationship. So therefore trust is key. And it's, in my opinion, it's really worthy to invest in building a trustful relationship and the collaboration with the implementation partner. There are partners. They just want to make you happy during the project phase, but they don't think, or don't care. I don't know what it means for you in your daily business. After the project, maybe you are planning as we do to run that application for several years. If you hire an implementation partner who is just trying to fill, fulfill all your wishes, maybe you won't be happy afterwards. For example, during the project, we had an, an idea has on internal, which we thought that would revolutionize the I G world. We were really proud of us. We spoke to our implementation partner and explained him our imagination and ask him by when he's able to implement our idea, surprisingly, he said, no, I won't do that. Unfortunately, he had really good arguments against our idea. We realized how silly that idea of us and what it would mean in operation. Later on what I wanna say with that is having a partner who is doing exactly what you want could cause problems for you later on,
But how can you increase the chance to find the right partner? We did that with our POC. We did, we defined a set of use cases and invited, as I said, two potential partners, the best from the process. We also insisted that at least the project manager and one to two people from the plant project team have to join that POC. So we are able to find out how the collaboration with them works. If they understand our questions, what we mean, and especially what we want at last point. At least as last point, I have something regarding technique, stick to product standards. I tell you, we over customized our last solution within the last 12 years, each minor update was a major upgrade for us. And, and it was not possible to manage that we had even, we would need some features or fixes. We had to skip an update just because of the effort it would be generated afterwards. So therefore for everything we are planning, I ask now the implementation partner, if that what he's doing, or what if that what we are requesting is within the product standard, or if we would leave now the safe Haven.
One of my highest project targets is to keep the solution upgradeable in health sauna on therefore I recommend what I have to do, what, or what I'm told to do is decline every request, which can't be solved within the standard product framework. So looking on the time, my little personal conclusion is that the approach to split the project in manageable phases and to choose not the easiest implementation partner, but the knowledgeable who has the garage to, to also say no. And that, that with a good reason works pretty well for Hisana. Thank you. Great.