Issue

Succinctly describe the issue or problem statement that this Decision addresses. Why is a decision required? What business or technical problem does it address?

The Conceptual Design phase included endorsement of a Future Neptune based solution for essential Syensqo logistics and warehousing operations via mobile handheld scanners. This is to provide online functionality but also ensuring that users can continue to perform daily tasks during any network dropouts. 

The SyWay design intent is to provide the business with unified mobile applications that support the different business scenarios. e.g. The app for processing Inbound Deliveries should support IM-NonHU, IM-HU and EWM scenarios, to avoid the need for users to select from separate apps depending on the scenario.

The two potential approaches considered to implement this solution are: 

Option A. HRC solution plus in-house build

Option B. Full in-house build

This KDD seeks to compare these approaches and evaluate the most effective option for Syensqo.

Recommendation

Summarise the recommendation being made for the reader, leaving the pro/con evaluation and exact decision-making process to the subsequent sections.

Option B: Full in-house build

This approach ensures a solution tailored exactly to Syensqo operational processes. This brings the following advantages:

• Gives Syensqo full control over the features, roadmap and security.
• Provides unified apps that support all Syensqo scenarios.
• Allows faster adjustments when the business needs corrections or changes. 
• Removes constraints related to changing existing apps from third parties.

Although full in-house development will mean a longer initial development time, requiring dedicated in-house resources, Syensqo can leverage the existing standard SAP EWM mobile functionality, the existing Neptune apps used by Syensqo and the existing SyWay team members that have experience of building similar in-house developed global solutions for handheld scanners. 

Estimates for developments required to augment the HRC solution and for the full in-house build attached: SyWay Neptune Mobile Apps - HRC.xlsx

Background & Context

Explain the context in which the decision is being made.

Neptune is a Norwegian company whose Neptune platform is designed to create and deploy mobile applications that interface seamlessly with SAP applications. As a SAP-native solution, Neptune enables efficient integration while minimizing the need for middleware. The platform integrates multiple data sources and environments into a single launchpad or view.

Syensqo has rolled out the Nereid project to selected plants and warehouses. The Nereid solution is a Neptune-based mobility solution, which sits on Neptune DX Platform SAP Edition, including a set of business tailored applications which support and manage the site logistics and warehouse operations.  

During the Conceptual Design phase, a decision was made to continue using the Neptune platform with the Future Neptune Solution, which will provide warehouse users with an unified view of both logistics and warehouse management functionalities within the SAP S/4HANA environment. It will not only offer online capabilities, while supporting network dropouts to ensure operational continuity, but also minimize change management impacts, facilitating a smooth transition to SAP S/4HANA. More details are described in KDD025 - Mobility Solutions in Logistics and Warehouse Management Processes.

Depending on the future process design, the decision will be made in the Detailed Design phase, whether to develop highly customized applications in-house or utilize third-party vendor pre-built applications with reasonable enhancements.

Assumptions

Clearly describe the underlying assumptions which informed or limited the choices available, or impacted the decision: cost, schedule, regulatory requirements, business drivers, country footprint, technology, etc. Include links as necessary. This section is important because a future change in circumstances might invalidate some key assumptions, which then prompts a decision to be revisited. 

1. The scope of this KDD excludes the mobility solution for Plant Maintenance (PM), which is handled by KDD072 - Mobility Application for Enterprise Application Management. 
2. The as-is handheld functionality will be harmonized to align with the SyWay program principles. However, the future mobility solution must continue to meet all relevant business needs. 
3. This KDD included an assessment of the potential vendors offering pre-built Neptune solutions.
4. A separate assessment will be carried out to determine the scale of hardware and infrastructure required for sites planned to roll out the future mobility solution. 
5. A review of existing hardware and infrastructure will be conducted separately for sites have already implemented the as-is mobility solution.  
6. Any third-party Neptune partner solution will be augmented, via additional in-house app development and enhancements, to meet all Syensqo specific business requirements. 

Constraints

Capture any constraints or limitations inherent to the recommended option. This could be aspects which, if changed or removed in future, could cause the decision to be revisited or invalidated. For example, a constraint might be that a new product has significant gaps in important functionality, which caused an older alternative to be recommended. If those gaps are closed in future, this might cause the decision to be invalidated.

While choosing full in-house build for the Neptune-based mobility solution is strategically sound, it may present certain constraints and challenges. These challenges are not necessarily unique to the in-house approach; but could also arise with off-the-shelf partner solutions, although in different forms and degrees.

• Project Timeline Constraints

The SyWay program involves both the core S/4HANA transition and end-to-end process reengineering. In parallel, the development of the Neptune-based mobile applications will proceed as a separate but closely linked workstream. This parallel execution increases the complexity of coordination, particularly in areas such as integration testing, user training, and change management. Additionally, any design changes within the core S/4HANA program may have downstream impacts on the handheld application design. 

To mitigate these risks, it is essential to establish an integrated project plan that clearly defines interdependencies and coordination points between workstreams. This includes aligning on shared milestones such as test cycles, integration checkpoints, and readiness gates to ensure consistency and alignment throughout the program lifecycle.

• Resource & Skills Constraints

In-house development requires the project team to have the necessary skills and resources. Without proper planning and prioritization, key teams such as development, QA, and SAP functional resources may become overstretched during the transition. To mitigate this risk, it is essential to establish a dedicated sub-team focused on the mobility solution, prioritize high-impact use cases, and phase the delivery accordingly. Additionally, creating a centralized repository for shared design documents will promote alignment across teams. Cross-training SAP and mobile application developers on basic integration principles can also help reduce reliance on a small group of specialists and foster stronger cross-functional collaboration. 

Impacts

Describe the impact of the decision on other aspects such as other processes, infrastructure, other SAP modules or systems, data cleansing and migration, developments, automations, interfaces, in-flight projects, etc.

Going with full in-house build as part of SAP S/4HANA transition doesn’t only affect the mobility solution itself, but may have broader cross-cutting impacts on other areas of the project, such as the process, integration among different modules and IT landscape etc.

• Process Alignment & Optimization

Heavy involvement are needed from process owners to define/refine logic within Neptune apps, as well as the greater alignment between business and development. The custom apps may preserve existing, non-standard processes rather than adopting S/4HANA best practices.

• Integration with Other SAP Modules

The mobile apps will need to not only be able to handle warehouse related activities, such as goods receipt, goods issue etc. The solution also needs to cater for different warehouse structures, such as IM based with and without handling unit management and EWM based warehouses, and being able to interact with other function modules such as production material staging, goods issue and goods receipt and Transportation Management. General support is also needed batch management, label printing and item serial numbers.

• Custom Development Governance

An in-house approach increases the custom footprint, which adds to future maintenance effort, and could also mean more regression testing is required. In-house developments need strict development standards, code reviews, and versioning standards across Neptune and SAP ABAP. When there are multiple teams involved, this could bring the risk of inconsistency among different teams. 

Business Rules

The decision may translate into business rules which enforce the decision and will require configuration. List these business rules here. For example, "An Outline Agreement cannot be created via the RFQ process. An awarded RFQ can only result in a Purchase Order". 

• The selected future solution should be implemented at sites where the as-is mobility solution is already in place and to all other plants that will benefit from the functionality.
• To roll out the solution to other relevant Syensqo plants, the cost-benefit should be evaluated while considering site-specific conditions/hardware regulations such as explosion and flammability risks. 
• All plants using handling units will need to use the mobility solution for handheld scanners.
• Plants using the mobility solution will need to ensure sufficient mobile devices to support the execution of the daily operations and exceptions.
• To rollout a single device, to be used globally at all locations that do not have an ATEX safety requirement and a single device to be used globally at all locations that have an ATEX safety requirement. Ideally the ATEX compliant device would be an intrinsically safe version of the standard global device. Limiting the number of models used globally facilitates the mobility solution build regarding the scanner interface, device operating system version and software and a standard device staging process. This approach also facilitates device support.

Options considered

List the options (viable options or alternatives) you considered. These often require a longer explanation with diagrams, or references to other documents (links are best, but attachments are also possible). Use enough detail to adequately explain what you considered so that a project or business stakeholder reviewing this decision will not come back and ask "did you think about...?"; this leads to loss of credibility and questioning of other decisions. This section also helps ensure that you considered enough suitable alternatives rather than just copy/pasting SAP's recommendations.

Business Requirements

A study has been conducted on the functionalities of the as-is Neptune solution. Due to the presence of two SAP instances, there are duplications, overlaps or inconsistencies in some functions. While the existing functionalities serve as the foundation for the business requirements, they will be harmonized to align with the principles of the SyWay program and adapted to meet the evolving business needs. For a detailed overview of as-is mobile functionalities, refer to the attachments on this KDD.

See attachment: Overview of As-Is Handheld Functionalities.xlsx

Based on the analysis of the as-is Neptune functionalities, the SyWay scope and workshops, to effectively support the logistics and warehouse operations, the Future Neptune-Based Solution should address the cross process business requirements, user experience and technical dimensions, as outlined in the table below.

Option A: HRC solution plus in-house build

Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly

Solution Overview

With this option, Syensqo will select the pre-built solution from HRC, and add further developments to fulfill the additional business requirements of Syensqo.

HRC provides a suite of ready-to-deploy Neptune mobile applications that cover key logistics and warehousing operations, backend integration with SAP S/4HANA, and run Fiori-style Apps optimized on Android-based industrial handheld devices. 

To fully support the above business requirements, the HRC solution will need to be augmented and enhanced for Syensqo specific needs. The customizations would include:

• Custom development of apps to meet requirements not supported by HRC. e.g. LE-HUM and TM functionality.

• Enhancements to pre-built apps (e.g. additional validation or operation logics)

• UI/UX adjustments for improved usability on handheld devices

• Localization or language support if applicable

Vendor/Partner Engagement

To identify a potential pre-built solution, a partner search was conducted using information on the Neptune Software website. The Config Team and HRC were the two official Neptune partners selected for further analysis as they both provided pre-built solutions. The matrix below presents an overview assessment and the summary findings based on a series of demonstration and discussion meetings. The full list of vendor partners initially assessed is attached: Neptune - Partner Study.xlsx.

The Config Team's heavy reliance on RF Framework configuration (Both standard EWM, Custom EWM and custom IM) would add a burdensome overhead, especially for customizations to standard PreBilt applications and to in-house built applications. With this approach we would be reducing the benefits already provided by the decision to use Neptune, where this config is unnecessary.

The user interface of PreBilt was also basic compared to the impressive user interface from HRC.

For these reasons it was decided to only consider the HRC solution for this KDD.

 Option B: Full in-house build

Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly

Solution Overview

With this option, a Neptune-based mobility solution will be fully developed as part of the SyWay program. The mobile apps will support the required logistics and warehouse operations in S/4HANA, fulfilling key functional and technical requirements:

• Align with SyWay program principles and requirements
• Enable real-time data capture, validation and postings via mobile handheld scanners.
• Provide unified applications for end users, based on process. e.g. A single app for Processing Inbound Deliveries, rather than separate apps depending on IM and EWM.
• Application functionality designed specifically for Syensqo requirements
• Support SAP S/4HANA integration with components such as Embedded EWM and TM
• Multilingual support
• Fiori-like responsive UI via Neptune
• Mobile transactions monitoring report

Implementation Team

By choosing the full in-house developments option, the implementation team must be carefully structured and resourced to handle both technical and functional complexities, while aligning with the overall program.

• Skill & Expertise Requirements

Both SAP functional and technical expertise will be required, for example, the functional expertise on SAP IM/EWM/Handling Unit/Serial Number Management etc, the Neptune platform expertise on App design with SAPUI5/Fiori principles and b ackend integration via ABAP and OData etc., the integration / middleware expertise on SAP gateway, OData publishing, and interfacing mobile apps with printers and scanners, as well as mobility & UX expertise on UX design following Fiori guidelines etc.

 Here is a role and responsibilities matrix to consider.

Evaluation

Outline why you selected a position. The best format could be a pro/con table (sample below), but is up to you as the author. You must consider complexity, feasibility, cost/effort to implement, but also ongoing operational impact and cost. You must consider the program principles and explain any deviations in detail. This is probably as important as the decision itself.

	Option A  HRC Solution plus In-House Build	Option B Full In-House Build
Function Fit & Customization	Based on a high level requirements review, the HRC solution provides coverage of around 65% of the listed requirement items.   This does not include any requirement weighting however. e.g. HRC does not currently provide LE-HUM functionality which will be a significant effort to build in-house. Not clear how additional Syensqo scenarios can be embedded in existing pre-built apps to align to the unified applications design. Changes to standard HRC apps could be constrained or blocked by the HRC design or roadmap.	High degree of customization, as Syensqo can design the solution to fit the specific business requirements.
Scalability	Generally scalable, as HRC apps will be designed for a wide range of use cases. Could have limitations in extreme scaling scenarios. Requires careful design and ongoing monitoring.	Scalability can be tailored to business needs Easier and quicker to resolve any performance issues since Syensqo will have complete control of both front and back end.
User Experience (UX)	Impressive User Interface. Best seen to date for Neptune apps.	Syensqo will have full control over the design and user experience. User Interface can be inspired by HRC approach Achieving a high-quality, intuitive UX may take more time and effort.
Integration with SAP S/4HANA	Neptune apps are built inside S/4HANA.	Neptune apps are built inside S/4HANA.
Time to Implement	Estimate of approximately 740 man days to build additional functionality required by Syensqo and test existing HRC apps. This does not include changes to standard HRC apps.	Estimate of approximately 1160 man days to build and test Syensqo solution. Time to build the additional functionality required for the HRC approach is 64% of time to build full in-house solution. SyCom team can leverage from standard SAP EWM mobile apps and experience and lessons learned from other builds of global Neptune logistics and warehouse solutions.
Cost Estimates (euros)	In-house build: 800k 25 days HRC Support : 20k* Annual licensing: 375k to 400k** *Using current mixed profile rate **Using mid point of licensing prices, between catalog and optimized prices, for 800 and 1500 users.	In-house build: 1.25 MM
Maintenance and Support  (** Country Base, Language etc.)	HRC released 4 updates per year. Although HRC advised that these updates were not mandatory Syensqo would need to regularly update. HRC Consulting is the current partner for the support of Neptune apps Vendor updates require full regression testing.	Syensqo will have full control over updates and maintenance but must allocate own resources to manage it.
Security	Need to rely on the HRC solution security control capability.	Better control over security policies and internal access protocols compared to vendor-hosted apps.
Innovation and Future-Proofing	HRC solution is currently continuously updated. Vendor updates may not always align will Syensqo requirements.	Flexibility to incorporate new features and innovative technologies.
Cost Considerations	Initial Investment Licensing and subscription costs. Lower initial cost. On-going Costs Maintenance, updates, support costs. Ongoing fees.	Initial Investment Development costs (including resources and training). Higher initial cost. On-going Costs Maintenance, bug fixing, future upgrades, and resource requirements for ongoing support. Potentially lower long-term maintenance.

See also

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log