Project Story

Boyner Group, Turkey's leading store, and fashion retailer provides services in different retail formats ranging from multi-story merchandising to private brands, from e-commerce to mobile applications with its 68 years of experience with 4 group companies, 101 stores, e-commerce sites, mobile applications, and more than 8,000 employees.

Boyner Group, with a consolidated turnover of TL 4.5 billion in 2019, is the most important business partner of many giant brands in Turkey and abroad with millions of customers and online and offline sales channels.

Current Structural Weaknesses and Project Needs

Boyner Group, which manages its current business volume with SAP ERP, was receiving support from 2 different suppliers with different SLA levels for the Boyner project, which is one of the largest SAP projects in Europe in the retail sector it was managing before its cooperation with Rasyona and Bulutistan.

During this period, the group, which had to face long backup and recovery times due to the different service levels offered by the project suppliers, frequently encountered very long downtimes of 8-10 hours originating from the data center from which the service was received. In addition, they had to wait 2 days for any support request and 3-6 days for a solution.

Aiming to eliminate all these disruptions in business continuity, Boyner Group wanted to move the SAP HANA infrastructure, which constitutes the backbone of the region's largest retail enterprise resource planning (ERP) system, including 101 stores in 37 provinces of Turkey, to the cloud base. Boyner Group also aimed to run more efficient disaster recovery scenarios by shortening the current processing times and achieving a sustainable cost advantage in IT operations in the medium-long term.

The highlights as a result of the Vulnerability Analysis are:

• The SAP project managed by two different suppliers was causing disruptions in business continuity due to the different SLA levels offered by the suppliers.
• Different SLA levels carried out with different suppliers significantly disrupt business continuity, HANA infrastructure is not positioned on the cloud base, bringing linearly increasing transaction times with the increasing number of transactions of the group,
• Exponential increases in IT operation loads, especially backup - recovery from backup (disaster management transfer times) and report generation,
• The linear increase observed in hardware investments due to non-scalable infrastructure,
• The high exchange rate risk brought by the current exchange-based service agreements,

Solution Plan and Implementation

The largest HANA infrastructure in the region, owned by Boyner group, was moved to Bulutistan, which operates an ISP-independent and fully redundant data center infrastructure, with minimum interruption and a 100% success rate, at the end of the 7-month productive project period within the scope of the project, with the cooperation of Rasyona and Bulutistan.

Effective and efficient project management was initiated with AGILE management.

Periodic meetings and joint teamwork of 3 different teams were planned before and after the transition. Transition procedures were prepared with HA and FKM tests, and DR (Disaster Recovery) services that would maximize business continuity within the scope of managed services were defined. Disaster scenarios were determined by completing HA (High Availability) and DR (Disaster Recovery) tests. N+2 data center environment has been prepared that can take instant «application consistent backup» and store the backups it takes in 2 different environments. In the project where Bulutistan from the IaaS layer and Rasyona from the system management is responsible, a single SLA contract was implemented. The exchange rate risk on the group was zeroed by switching to a TL-based agreement.

Advantages Provided

The impact report of the Boyner Group project, in which the transition to the Bulutistan infrastructure, the pioneer of the SAP Hana Cloud market, was made as a result of the 7-month productive project process, is given below.

Business Continuity Impact

• Backup times were reduced from 12-20 hours to 2 hours. By performing the restore test, the restoration process was completed in 2 hours.
• HA (High Availability) and DR (disaster recovery) tests were completed and disaster scenarios were determined. 65% gain in HA Replication time and 50% gain in DR Replication time. 80% reduction in possible downtime

Performance Impact - OS

• I/O write throughput increased from 13 MB/s → 37 MB/s. It has been achieved to exceed 20 MB/s, which is the SAP standard. Memory recovery work decreased 2502 s/day → 266 s/day, below the 1200 s/day recommended by SAP Standards. An average of 2% memory gain was achieved on Hana servers.
• CPU usage decreased by around 5% on the FMP Hana server. Overall 15% Memory gain on application servers. An improvement of around 5% was achieved in CPU usage on application servers.

Performance Impact - General Usage

• Analysis was carried out on the 10 most used reports.
• Average response times were improved between 30% and 65%. When the average value of the recovery times was calculated, a 35% improvement was achieved.
• Your reports
  • When the total response times were examined, it was seen that the total time, which was 12.6 hours in the 1 week before the transition, decreased to 3.4 hours after the transition. A gain of 74% was achieved in the total response time.

Performance Impact - End User Gain

• When the HTTP web service response time was examined, it was seen that there were 24 million transactions and 3,192 hours in 1 week before the transition, and this period was 20 million transactions and 1,177 hours after the transition. It was observed that the gain obtained as Web Service was 56% after the transition.
• The response time of DIALOG users was 680 thousand transactions in 1 week before the transition and 799 thousand transactions and 330 hours were reached after the transition from 349 hours. It was observed that the gain obtained as DIALOG was 19.5% after the transition. When examining all task types (DIALOG, BTC, UPDATE, RFC…) on the database side, a 27% gain was achieved in average response times.