TRANSFORMING A BUSINESS FROM LICENSE SELLING TO SERVICE PROVIDER - - PowerPoint PPT Presentation

Classification: Restricted (V2)

TRANSFORMING A BUSINESS

FROM LICENSE SELLING TO SERVICE PROVIDER

LEEN BLOM March, 2019

Classification: Restricted (V2)

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

ABOUT ME

• Manager Research & Development at Centric
• Background in software development, database management,

application design, head software development, architect, R&D manager

• Consultant, Manager consultancy, R&D manager
• Now member of team Enterprise Innovation
• Member of Contact Group Universities, guest lecturer at Rotterdam

University of applied sciences

Classification: Restricted (V2)

Classification: Restricted (V2)

Classification: Restricted (V2)

CENTRIC

• One pillar: Software Solutions

– We build applications for

• Public Sector
• Supply Chain
• Financial Sector
• Horizontal markets

– About 100 software applications

Classification: Restricted (V2)

AGENDA

• From traditional to SaaS
• From technical debt to up-to-date
• Software Quality

Classification: Restricted (V2)

FROM TRADITIONAL TO SAAS

Classification: Restricted (V2)

Reality of our portfolio

Classification: Restricted (V2)

Our approach until 2016

Classification: Restricted (V2)

Centric SaaS

Classification: Restricted (V2)

SAAS TRANSFORMATION PROGRAM

• Goals

– Help organisation to transform applications to services – Help organisation to build a platform for services – Help organisation to automate development to operations

• For

– PSS, HR&PS and SCS – In cooperation with Romania, Lithuania

• Team

– Christiaan Konstapel, Leen Blom, Quirijn van der Goes, Cosmin Sontu*, Rene Bliekendaal, Frank de Nijs, Gert-Jan Verkerk

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

TRANSFORMATION PRINCIPLES

• Accept all maturity levels of SaaS

– Applications can move easily and improve later (“vernieuwbouw”)

• No major dependencies between transformation projects

– Each transformation can have its own pace and lead time

• Use common platform

– Enables us to share as much as possible and reuse components

• Automate, automate, automate

– Remove any manual task after software build: test, deployment,

• perations

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

PORTFOLIO ASSESSMENT

<- low importance

Cost

high importance ->

<- low

Added Value

high ->

Customer perspective

DEM Key2Financien Motion Motion Pay Motion PAY Non Profit Suite4Inkomen Suite4Jeugdzorg Suite4Werk Suite4Zorg Key2Belastingen Key2WOZ Key2BAG eDienstenSD Document Creation Burgerzaken Conductor Key2Betalen DIS Key2Zaken Portaal Leefomgeving

<- high

Investment low ->

<- low

Added Value

high ->

Centric perspective

large means feasable favourable

Classification: Restricted (V2) DEM Key2Financien Motion Motion Pay Motion PAY Non Profit Suite4Inkomen Suite4Jeugdzorg Suite4Werk Suite4Zorg Key2Belastingen Key2WOZ Key2BAG eDienstenSD Document Creation Burgerzaken Conductor Key2Betalen DIS Key2Zaken Portaal Leefomgeving

<- low importance Cost high importance -> <- low

Added Value

high ->

Customer perspective

OK: most in upper right corner Not OK: large applications high cost

Classification: Restricted (V2) DEM Key2Financien Motion Motion Pay Motion PAY Non Profit Suite4Inkomen Suite4Jeugdzorg Suite4Werk Suite4Zorg Key2Belastingen Key2WOZ Key2BAG eDienstenSD Document Creation Burgerzaken Conductor Key2Betalen DIS Key2Zaken Portaal Leefomgeving

<- high

Investment low ->

<- low

Added Value

high ->

Centric perspective

Not OK: most applications high cost OK: modern applications in upper right corner

Classification: Restricted (V2)

INTERMEZZO – WORKSHOP

• Work in small groups – 10 minutes
• The situation: we need 20 men year for removing technical

debt, but we got a RFP from important customer, requiring a change of 7 men year, delivery time 1 year. Team size is 8 including product manager and developers. You can’t do both.

• Decide what you would do and why:

– Ignore RFP and start renewal?

• or

– Ignore technical debt and deliver to customer?

Classification: Restricted (V2)

WORKSHOP: DISCUSSION

• What is your choice? Why?

Classification: Restricted (V2)

WORKSHOP

• After 1 month a new RFP comes in
• What would be your choice?
• Does it differ from first?

Classification: Restricted (V2)

TAKEAWAY

• Men year to rebuild: thousands

– (it is a measure, to know the size of our portfolio) – Portfolio in transition to Software-as-a-Service – Renewal programs are underway – Getting grip on quality is very important

• Maximum project size in our experience: 30 MY

Classification: Restricted (V2)

EXAMPLE

TAX SOFTWARE TRANSITION TO SAAS

Classification: Restricted (V2)

KEY2BELASTINGEN IN FIGURES

• Estimation 37.721 FP
• 332 men year
• Value 37 Miljoen
• 30 developers

Object # DB Inputs Outputs Selections

Forms 1.578 1.578 1.578 Batches 465 465 465 Workflows 141 141 Letters 71 71 Scripts 232 232 Reports 489 489 Database procedures 5.929 Managestabels (*1) 2.401 2.401 Total 11.306 2.401 2.043 838 2.138 Points per function 7 4 5 4 Total no FP 16.807 8.172 4.190 8.552 Total 37.721

Classification: Restricted (V2)

CHALLENGE IS BIG

• Competitiveness declining
• Complexity increasing
• Technology is old
• But still functional very fit: best in class, to be honest
• How to convince the board about an approach?

Classification: Restricted (V2)

BUSINESS CASE LOGIC FOR A BOSS

• This will always work

– Lower cost, higher turnover

• But how??
• Another trick

– We will completely rebuild to new modern application

• But what is the cost? How long will it take?
• Remember: >300 men year
• So we need to play the technology card

– We do some magic – Which will lower cost and increase turnover

• How??

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

BUSINESS CASE LOGIC

March 25, 2019

TITLE PRESENTATION

Smaller applications Less software Webbased UI 3 tier model (REST API) Higher productivity Less bugs Less management Lower cost New business Modern applications Customer retention SaaS ready Increasing turnover

Classification: Restricted (V2)

REDUCTION

• Removing duplication from 33 modules to 21 components is

37% decrease of software volume

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

MINIMIZE IMPACT

March 25, 2019

Subject Adres

K2DDS Data Ma- kelaar LV K2B GISVG K2 Park- eren Cipal Baker ware

Minor change Major change No change

Classification: Restricted (V2)

COST REDUCTION

• Netto Present Value 1.329
• Cost reduction up to 35% in 2026 • Break-even point 2021
• Note: not real figures, but same order

March 25, 2019

TITLE PRESENTATION

Cost reduction

2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 Maintenance %

• 4%

8% 12% 16% 19% 23% 27% 31% 35% Maintenance K€ 100 300 400 500 700 700 900 1000 1000

Cumulative

2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 Spending 200 800 900 400 400 Reduction OH 100 300 400 500 700 700 900 1000 1000 Total cash flow

• 200
• 800
• 800
• 100

500 700 700 900 1000 1000 Cumulative

• 200
• 1000
• 1600
• 900
• 100

500 1200 1400 2300 3300 4300

Classification: Restricted (V2)

FROM TECHNICAL DEBT TO UP-TO-DATE

25-03-19

Classification: Restricted (V2)

RENEWAL PROJECT

• Example department

– Human Resource & Payroll Solutions (HRPS)

Classification: Restricted (V2)

CHALLENGE IN 2012

• Centric is a company of many acquired organizations
• HRPS is a merger of 3 companies

– 120 employees

• For HR and Payrolling each 3 applications + selfservice portal

– Interlinked – Markets: profit and non-profit – HR products licensed – Payrolling: software as a service

• Organization sub-optimal

– 6 product management groups

• Overall competitiveness declining

– But still profitable!

YouPP

PIMS@all

PMvdO

PersMaster

LPS PASO PayMaster

Classification: Restricted (V2)

CHALLENGE IN 2012

2016 2012 2018 Cost per unit Cost reduction goal Renewed software

Classification: Restricted (V2)

OVERALL PLAN

• One product line for HR and Payrolling
• Delivered as Software-as-a-Service (SaaS)
• Self-service for employees (ESS), managers (MSS)
• Deliver first MVP in 2016
• But how? And what would be the cost and lead time?
• Approach

– Part 1: Decision scenario for upgrading HR systems – Part 2: Decision on what payrolling system should remain

Classification: Restricted (V2)

ESTIMATIONS NOTES

• Estimations are lean & mean

– If something already works, do not change it – When developing to bridge functional differences, rebuild it “as is” and not “fancier”

• The team that has to develop the new functionality made the

estimation

• All estimations are high level effort estimations, not a planning

– Does not include project overhead – Does not include the performing of the conversions

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

HR SYSTEMS

• Comprises functionality for

– Employees, benefits

• ESS: Employee Self Service
• Hours, leave, pension

– Managers

• MSS: Manager Self Service
• Approvals, promotions

– HR Professional

• PSS: Professional Support Services
• Contracts, payroll

Classification: Restricted (V2)

4 HR SCENARIOS

• eHRM

– Incremental scenario

• Approach until 2012, many intermediate deliveries
• All levels rebuilt

– Greenfield scenario

• Completely rebuild the HR software
• All levels rebuilt, big bang delivery

– Upgrade scenario

• Refresh HR software and make it Cloud-based
• ESS and MSS rebuilt, PSS upgraded, big bang

– Time to market scenario

• Encapsulate HR into a Cloud-accessible application
• ESS and MSS rebuilt, PSS virtualized

March 25, 2019

TITLE PRESENTATION

t ?

2016

?

Classification: Restricted (V2)

EHRM SCENARIO CONSTRAINTS

• Constraints for all scenario’s (simplified):

– Development & testing for eHRM in Romania – SaaS only, multi tenant, upgradable UI for eHRM

• Worst case / best case percentages are based on estimation

confidence levels of development team

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

GREENFIELD SCENARIO DESCRIPTION

• eHRM consists of newly developed

self service and HR functionality as

• ne new solution
• Completely rebuild of software
• Result: All levels rebuilt, big bang

delivery

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

GREENFIELD SCENARIO ESTIMATIONS

March 25, 2019

TITLE PRESENTATION

Greenfield scenario Worst case Expected Best case (with one profit and one non-profit payroll) Factor Effort Factor Effort Factor Effort HR Systems Functionalities: RO HR Systems Functionalities: NL YouPP Functionalities: RO YouPP Functionalities: NL Architecture: RO Architecture: NL Database Conversion: RO Database Conversion: NL Reporting: RO Reporting: NL Future functionalities current products: RO Future functionalities current products: NL

Years 132 100 67

Classification: Restricted (V2)

GREENFIELD IMPOSSIBLE

• In our experience 30 MY is maximum
• This is a 13-17 team developing 3 years
• Team size 7 +/- 2 is golden rule in Agile

Classification: Restricted (V2)

UPGRADE SCENARIO DESCRIPTION

• eHRM consists of newly developed

self service functionality integrated with upgraded versions of PIMS & PersMaster

• PIMS & PersMaster are changed to

become SaaS solutions

• ESS and MSS rebuilt, PSS upgraded,
• Big bang delivery

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

UPGRADE SCENARIO REMARKS

• Takes more effort to upgrade PIMS than to build from scratch
• PersMaster has to be rebuilt for an estimated 80%
• PersMaster needs same effort as in greenfield scenario
• More complex than greenfield scenario
• Poor productivity: effort in understanding Delphi & Dutch
• Incremental model and delivery is hard to manage
• Conclusion

– Estimation will always be higher than greenfield scenario – So we skipped this scenario

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

STUCK

• What should we do?
• We tried a minimal scenario, primarily targeting on time to

market

– ESS, MSS rebuilt – PSS stays single instance but delivered as SaaS

• A per-customer environment integrated with ESS, MSS

– Full SaaS will be started later

Classification: Restricted (V2)

TIME TO MARKET SCENARIO VALIDITY

• End users using our software

– 80% will use ESS -> modern software – 15% will use MSS -> modern software – 5 % will use PSS -> virtualized software

• We decided we can live with that low

exposure of “old” software

• Note: sometimes the professionals are

the only people that decide about buying this kind of software…

Classification: Restricted (V2)

TIME TO MARKET SCENARIO DESCRIPTION

• eHRM consists of newly developed self

service functionality integrated with upgraded versions of PIMS & PersMaster

– ESS and MSS modern

• PIMS & PersMaster are hosted to become

SaaS solutions

– Customers have their own virtual HR environment – PSS remain “old” software

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

TIME TO MARKET SCENARIO ESTIMATIONS

Time to market scenario Worst case Expected Best case YouPP Functionalities: RO YouPP Functionalities: NL Architecture: RO Architecture: NL Database Conversion: RO Database Conversion: NL API: RO API: NL Future functionalities current products: RO Future functionalities current products: NL

Years 28 23 17

March 25, 2019

TITLE PRESENTATION

Classification: Restricted (V2)

PART 2: PAYROLL SYSTEMS

Classification: Restricted (V2)

EFFORT SUMMARY

• Commitment for aim: delivery in 2017
• …and first customer in summer 2016
• Current status: 40000 end users, will grow to

March 26, 2019

TITLE PRESENTATION

Years One profit product line 3 One non-profit product line 10 eHRM time to market scenario 23 Total: 36

Classification: Restricted (V2)

Classification: Restricted (V2)

SOFTWARE QUALITY

SOFTWARE IMPROVEMENT GROUP

Classification: Restricted (V2)

SOFTWARE IMPROVEMENT GROUP

Classification: Restricted (V2)

PORTAL

https://portal.sig.eu/monitor/#/dashboard

Classification: Restricted (V2)

SOFTWARE QUALITY

• Arguably the most important paper that serves as a foundation for the SIG model, and certainly

the first one, is the QUATIC2007 paper (see https://ieeexplore.ieee.org/abstract/document/4335232 for bibliographic data, paper is attached).

• SIG's model is based on a benchmark, but that benchmark is not mentioned in the QUATIC paper.

That started with our ICSM2010 paper (see https://ieeexplore.ieee.org/abstract/document/5609747): this one introduces the concept of determining metric thresholds from benchmark data.

• SIG rates maintainability of codebases in terms of a 5-point star rating. That rating is described in

the SQJ2012 journal paper (see https://link.springer.com/article/10.1007/s11219-011-9144-9). Because this paper is somewhat younger, it contains quite a few references to other papers about the SIG model.

• The architecture metrics are a relatively recent addition to the model:

see https://ieeexplore.ieee.org/abstract/document/5959722.

Classification: Restricted (V2)

THANK YOU! ANY QUESTIONS?

Leen Blom +31-653562767 leen.blom@centric.eu