Request for Proposal

Conti Belt Inspect Software

RFP No. 1
Date of Release: May 1st 2018

1
 TABLE OF CONTENTS

1. Overview and Project Description .......................................................................................................... 4

1.1. Company Background .............................................................................................................................. 4

1.2. Purpose and Intent.................................................................................................................................... 4

1.3. Scoping ....................................................................................................................................................... 5

1.4. Current System Situation ......................................................................................................................... 6

1.5. Legal Requirements.................................................................................................................................. 8

1.6. Timeline and Implementation Approach ................................................................................................ 9

1.7. Further Requirements............................................................................................................................. 10

1.7.1. Data Entry Mask .............................................................................................................................. 11

1.7.2. Data Analysis Dashboard .............................................................................................................. 12

2. GENERAL PROCEDURAL INFORMATION ...................................................................................... 13

2.1. Technical Requirements ........................................................................................................................ 14

2.2. Integration ................................................................................................................................................ 14

2.3. Languages................................................................................................................................................ 15

2.4. Testing ...................................................................................................................................................... 15

2.5. Authentication .......................................................................................................................................... 16

2.6. Roles and Permissions........................................................................................................................... 16

2.7. Service Management.............................................................................................................................. 17

2.7.1. General Service Management and Service Levels .................................................................... 17

2.7.2. Release Management .................................................................................................................... 17

2.8. Infrastructure ............................................................................................................................................ 18

2
2.9. Hosting and IT Cybersecurity ................................................................................................................ 18

2.9.1. General Remarks ............................................................................................................................ 18

2.9.2. Data Seggregation .......................................................................................................................... 19

2.9.3. Test- and Development System ................................................................................................... 20

2.9.4. Back-up and Recovery ................................................................................................................... 20

2.9.5. Licensing of Support Tools ............................................................................................................ 21

2.9.6. Virus Protection and OS Updates................................................................................................. 21

2.9.7. Data Life Cycle ................................................................................................................................ 21

2.9.8. Data Protection ................................................................................................................................ 22

3. Project Approach, Timeline and Other Details ................................................................................... 23

3.1. Project Management............................................................................................................................... 23

3.2. Training ..................................................................................................................................................... 24

3.3. On-site Support during first Go Lives ................................................................................................... 25

4. SPECIFICATIONS .................................................................................................................................. 25

4.1. Term of Contract(s) ................................................................................................................................. 25

4.2. Instructions for Submitting Proposals .................................................................................................. 26

4.3. Detailed Response Requirements ........................................................................................................ 26

3
1. Overview and Project Description

1.1. Company Background

With sales of €40,5 billion in 2016, Continental is among the leading automotive suppliers
worldwide. As a supplier of brake systems, systems and components for powertrains and
chassis, instrumentation, infotainment solutions, vehicle electronics, tires and technical
elastomers; Continental contributed to enhanced driving safety and global climate
protection. Continental is also an expert partner in networked automobile communication.
Continental currently has approximately 220.000 employees in 56 countries.

The Continental Corporation is divided into the Automotive Group and the Rubber Group,
and consists of five divisions:

- Chassis & Safety

- Powertrain

- Interior

- Tires Division

- ContiTech develops and produces functional parts, components and systems for the
automotive industry and for other key industries.

Within one of the Business units of ContiTech we can find the Conveyor Belt Group. This
Business Units operates with about 23 plants on a global base with approx. 6000
employees.

1.2. Purpose and Intent

The Conveyor Belt Group is looking for a IT based data input solution for findings in the
finish product inspection line of all production locations worldwide.
Additionally a main focus is a data analytics part (Dashboard) to analyze the data previously
collected on the shop floor.

The major focus is to make an easy to use user interface for data input, that can be easily
understood by all skill levels of employees.

4
 The Conveyor belts group is looking not only for a software that can handle our current core
processes, but also a software provider that has the capabilities to handle future growth and
automate other processes in the future. At the same time, it is important to ensure a well-
managed IT-service together with the IT-team of Continental.

Below are some of the core processes we wish to automate with a global database solution:

› Consultancy on the best practices in the implementation of such a tool

› Administration of all relevant data for the process, e.g.

› Master data of employees considering their respective organizational

structure (e.g. number of the employee, address, name, first name,
grade, Division, BU, Entering date company, planned pension)

› Interface to our SAP PP system as source of master data transfer and

transfer data from the tool into SAP, if applicable.

› Framework of the different plants: Data analysis both on plant level

and on corporate level (consolidation of the data from all plans into
predefined KPI’)

› Run Individual queries / flexible reports and analytics

› Adding of masterdata (new inspection machine, new employee, new findings

catalogue, language, plant, etc.) by a administrator within the business

› Enabling of workflows (approval chains) with different involved parties:

Producion supervisor, Production Manager, Quality manager, controlling

› Who will control what? Who will have access and/or right to read, execute?
Possibility to implement different access rights?

› Electronic pdf map of findings, excel reports of data collected

1.3. Scoping

Continental wishes to encompass the collection of data from the visual inspection of finished
product and measurements into the software for the data to be easily available for analysis
for structures problem solving. For a better understanding the Conveyor Belt Group´s tool
specifications, please consider the below listed details as well as attachment A describing all
requirements and its related questionnaire.

5
 Please provide customer references with a similar scope of services we are looking to
implement in the requested regions in Attachment B. Please specify which services the
customers are using at this time.

Additional requirements:

› Data: There is a specific need for data flexibility. All the imported and manually
entered data needs to be easily put in to customizable reports as well as a series of
standard reports

› Transfer of information: Ability for the vendor to receive several sources of data in
the initial data setup. (e.g. Excel or flat file format); Ability to import information from
SAP via barcode scan or a search of the production order.

› Access: Ability to enable different access rights based on roles and organization
(e.g. local Production/Quality, Shop floor employee, supervisor)

All requirements listed in the supplier questionnaire (Attachment A) are

also seen as necessary.

1.4. Current System Situation

In the various locations of the ContiTech Conveyor Belt Group, many different solutions are
used to document and store analysis data from product inspection. The intention for this
software is to replace all currently used solutions and to unify the documentation routines of
all CBG plants.
The inspection data collection process is based on manual data input using paper and then
in a next stage transferring this to an excel document, which is time consuming and labor
intensive. Moreover it is very difficult to generate global reporting and make aggregate
analyses.

The current operational system landscape is as follows: Windows 7 and 10, Microsoft
Internet Explorer version 11, Google Chrome 55, MS Office 2013 and 365. The e-mail
platform is being migrated from Lotus Notes 8.5.3 to Outlook (taking place in year 2018).

6
7
1.5. Legal Requirements

Continental requires an IT solution. To be compliant with the requirements stated in the

European Directive including the General Data Protection Regulation (GDPR) as well as in
the German data protection law, Continental prefers that any data storage shall be within the
EU, ideally in Germany.

Providers must prove that they are compliant according to the EU data protection.
Therefore the detailed description and implementation of all measures required by European
Directive including the GDPR as well as in the German data protection law must be
guaranteed by the provider. Due to the global scope of the project, providers must ensure
that they are compliant to any data protection requirements of all countries in scope.

8
1.6. Timeline and Implementation Approach
The project is going to be structured by an agile development process for customizations/
development of the software. This means that the development phase will be divided into
sprints of about 3 to 4 weeks. The sprints’ duration depends on the team’s experience level and
may vary during the project. The crucial point is that after each sprint, a potentially shippable
increment (PSI) gets deployed and is available to users for evaluation or even productive use.
Within each sprint, affected key users shall be involved in the development process:
The development team selects some features from the backlog
The team creates initial mock-ups or detailed descriptions for the chosen items.

Preferably, key users shall review these mock-ups and give further input.
At the end of each sprint, the PSI needs to be evaluated by key users. The benefit of this
approach is that the customer can verify functionality very early in the project, instead of having
to approve all functionality at the end of the project.
The implementation of the global inspection software solution will follow a timeline defined
below.

9
 Training (classroom/webinars) would start just prior to go-live.

1.7. Further Requirements

The provider should set up a detailed implementation plan with a suggested timeline.

All pricing indications for operating costs (e.g. license fees, maintenance, support, etc.) must
be based on a five-year model after implementation. Please use attachment C (pricing
template) to document costs.

Email notification have to be quoted as optional. The provider is expected to give a proposal
on the effort necessary for this task in the attachment C (pricing template).

The resources for the project team (Project Manager and Professional Services) of the
provider being considered to be assigned to the project must possess a proven track record
according to their roles and in comparable projects.

10
 Operational support should be ensured until a stable utilization of the tool. This should
include KPIs.

Architectural Topics:
* Architectural decisions: decisions that are made in favor of a certain approach, design
pattern or technology (or against it) should be documented here, including the arguments
that led to that decision
* Architectural components: describes foundation technologies and the system architecture
* Programming guidelines: specifies the criteria for code quality
* Programming guides: standard programming topics like UI development, error handling,
notifications, interface development, logging, etc. should be documented in short tutorials,
so that new developers can easily get in touch with the patterns and best practices of the
project

To make the system more self-explanatory and intuitive to use, status information of objects,
like test orders, should be displayed as words, not only as code – like “Released” instead of
just “A”, or “Process” instead of “P”.
However, there are exceptions to that rule. In some reports where lots of information must
be displayed in a compact way, the status codes should remain abbreviations.

As the system is used from different countries and time zones, date and time information
should be persisted consistently as UTC timestamps.

Data entry should be possible in inches and feet at certain sites. For later consolidation of
data on a global level an in software conversion to metric system needs to be planned for.

Two functions should be quoted separately:

Notification Escalation in case of out of spec product

Send E-Mails

1.7.1. Data Entry Mask

• Finding Selection based on Dropdown

• Dropdown based on Findings Catalogue
• Table/Touch compatibility
• Mandatory Fields
11
 • DB with data out of the Data collection
• Configuration for Plant differences
• Plant/Blet specific Findings Catalogues
• Automatic minute (Change History)
• Conti Cyber Security
• Versioning
• Offline treatment / Cache
• Activity Check (user still active)
• Zoom
• PDF
• Important interfaces
• Customized and standard Findings Catalogue
• Functionality as described in the process flowchart
• Language handling
• Support for metric and imperial system
• Possibility to add pictures on a finding or the repair of a finding

1.7.2. Data Analysis Dashboard

The data for the data analysis are collected from internal SAP systems and a database that
stores the collected failures from the belts. The data analysis should merge the data and
summarize them given some pre-defined visualizations and user input. The results are
displayed in an interactive dashboard. The dashboard should contain three main parts (tabs)
based on different levels of data summaries. They are described below. The selected data
sets can be downloaded as .csv or .xlsx files.

Requirements:

• Analytics Dashboard
• Graphic Findings analysis
• Graphic Belt analysis
• Overview per Belt
• CSV Export of Database

Interactive Belt analysis

12
 Within this tab of the dashboard the user should be able to select one specific belt that is
afterwards displayed. The user is able to see the belt specification and a failure map (belt
model), where each failure is displayed at its coordinates. If the user can click/or hover over
the specific failure an example picture is of that failure is displayed.

Overview Plots

This tab of the dashboard should give a general (region and/or plant wide) overview of pre-
defined KPIs (key performance indicators) the failures over a specified time range.
Selection fields:
- Plant
- Failure type
- Belt type
- Region
In total three plots should be displayed:
- X-axis: time, y-axis: KPI (sum of failures per 100m)
- X-axis: plant, y-axis: KPI (sum of failures per 100m)
- X-axis: press within specific plant, y-axis: KPI (sum of failures per 100m)

Pivottable display

This tab should provide a very flexible selection and visualization functionality, see e.g.
https://pivottable.js.org/examples/
The user can select and filter different pre-define columns from the database, e.g. plant,
region, belt-type, …. . It should also be possible to change the type of visualization, e.g.
barplot, heatmap, table, line-chart, … .It should be possible to download the generated
visualization.

2. GENERAL PROCEDURAL INFORMATION

Providers responding to this RFP are expected to provide Continental with information,
evidence and demonstrations that will permit awarding a contract in a manner that best
serves the interests of Continental. The provider is expected to respect the Sourcing
Guidelines as given in Attachment D.

13
2.1. Technical Requirements
a) Operating systems: General requirement from Continental is, that the tool runs on
Windows 7 and 10, Microsoft Internet Explorer version 11, Google Chrome 55, MS
Office 2013 and 365 including the diverse tools (i.e. Outlook, Teams, etc.).

b) Back-end integration: including a secure connection to our e-mail platform in Outlook

and SSO if applicable.

c) Performance optimization / user experience: The tool shall provide an optimal user
experience and shall be user friendly as well as flexible to adapt to further business
needs.

d) Configuration: The software offers broad configuration possibilities to enable the

flexibility needed for the different plants.

e) Data protection / security: All relevant data and the identity of the user must be
protected by sufficient mechanisms. The solution must implement a security concept that
protects leakage of data to third parties.

f) Compliance with German law: The tool must be complaint with relevant data
protection requirements (e.g. EU GDPR, BDSG in Germany, etc) of all countries in
scope is ensured (e.g. data privacy notification and consent page has to be available,
security measures in place, consent for cookie usage, data portability ensured, etc.). If
applicable are details, of country-specific regulations (e.g. new data localization law in
Russia or Cybersecurity law of China) covered?

2.2. Integration

The following integrations should be considered or mentioned in the proposal

Interfaces (Inbound):
• SAP interface to import ad-hoc data
• Interface to an inspection machine based on a camera inspection Module
Interfaces (Outbound):
• Collect data on a global database
• Pdf Export of individual Belts with an overview on findings/repairs/general data
• Please provide an overview of export data file types (e. g. csv, xls etc.).
14
 • Dashboard analysis on the collected data

Integration (to internal systems) ;

• The ability to integrate with mail servers. (e.g. to send automated mail notifications) Define
Additional Cost
• The ability to send encrypted E-Mail notifications. Define Additional Cost
• Usability
• Configuration to individualize plant specific parameters
• The solution is intuitive and requires almost no user training.
• Selection of findings per Dropdown menu
• Simple structured user interface
• As less textboxes as possible. Data collection through SAP export/dropdown menus
• The solution offers context sensitive help and an online documentation. (F1)

2.3. Languages

Implementation language will be Germany. The data analysis dashboard needs to be only
available in English.
The data input needs to be available in all languages listed in 1.6 in the roll out plan.

• End-User Interface for employees, instructors and Supervisors (including all error messages
and online documentation)
• Key-User Interface for administrators, system-administrators (including errors messages and
online documentation)
• Documentation
• User Help Desk
• Training Material
• English, German, Hungarian, Chinese, Portuguese (Brasilia), Finnish, Slovakian, Spanish
(Mexico, Chile), Serbian, French-Morocco, Greek-Syma
• Additional languages
• The ability to add additional / maintain existing languages to the system by customization.
• The ability to add / maintain existing languages by uploading translation packages.
• The ability to choose the language for E-Mail notifications per user.

2.4. Testing

The implementation partner is expected to provide / create custom made test templates
based on their best practice experiences together with the project team which enable the
project team to measure the configuration progress.

15
 The testing of the software should be done in constant Jour fixes during development.
Then the system will be tested in the production environment.
Especially this includes the integration testing and the on-site testing before the go live of
the pilot location in Germany/Northeim.

Please specify if there are mechanisms to refresh data or to replicate specific data from one
instance to another instance.

2.5. Authentication

It has to be ensured that Continental’s authentication and IT Cybersecurity requirements

are fulfilled. This means generally that only authorized users are allowed to access the
software.

At the same time we are generally open for any best-practice approach which is technically
feasible for Continental and fulfills our authentication and IT Cybersecurity standards.

Please describe your technical concept to ensure the authentication principles above.

2.6. Roles and Permissions

User classes should include the following:

Data Dashboard:
• Access for personnel not involved in the inspection process for data analysis (not
restricted)
• Master User to make changes in the reporting structure and set up new plants and
masterdata

Inspection Data Entry:

• Data entry for shop floor workers
• Authorization for release of out-of-spec product for supervisors
• Authorization for correction f wrong entry for supervisors
• Administrator (full access)

16
2.7. Service Management

2.7.1. General Service Management and Service Levels

It is expected that the provider develops a service management concept together with
Continental based on best practices.

This concept has to include:

- a third level support provided by the provider to support our internal second level IT
support in case configuration issues as well as any kind of technical problems (replication of
data, connection to SAP, data entry issues, etc.).
- an efficient way to address and to get solved technical issues and software bugs
- a concept for regular patches and release updates (see above)
- flexible elements to increase online support during the roll out after the pilot location

Please specify which service levels (IT support, system availability, support availability,
response and resolution times etc.) are offered with which parameters at which rates.

Additionally, the provider is expected to offer on-site support during the first pilot
implementation around February to May 2019 (as part of your proposal).

It may be requested as well to buy additional support for further enhancements. Please
describe if this kind of service could be offered by you based on time.

2.7.2. Release Management

The service management concept should as well include a release management concept.

Please specify in your proposal

- how frequently and with which scope new releases are delivered
- how the testing of new releases takes place before they are delivered and how
Continental can test before the release is in place
- if options exist to provide certain new functionality not with full scope and not before a
certain moment
- how hot fixes / patches are implemented in between

17
2.8. Infrastructure

It is expected that the software runs smoothly and very stable in the overall environment of
network, hardware and software. Please provide the speed rates, response times for the
different sections of the software (calculations, reporting, front-end, etc.).

We are expecting data entry users to be in the system in all time zones worldwide
simultaneously at the same time. During the pilot max 21 data entry users are
simultaneously working. After global roll out the number is estimated to be 400 at peak
times.
The use of the data Dashboard for evaluation will be less frequent and by a max of 50 users
simultaneously.

Please define specific infrastructure requirements to achieve this. On-Premise as well as

Cloud Solutions shall be considered.
The Software should be usable and fully compatible with the following browsers:
Google Chrome and Internet Explorer.

We have a constant internet connection in case of data analysis for the dashboard function.
For the data entry on the shopfloor our tablets and Laptops have wifi connectivity. This might
be interrupted by crane signal interference. A cache of up to 30 min would be required. The
data entry needs to be possible even if the import of data from SAP might not be possible.
Later connection or manual input might be solutions.

Please make a suggestion for the server structure. Central in headquarter? Local at each
site? Is this provided by Continental or can the Supplier provide this.
Regardless of network latency (which may well amount up to 280 milliseconds for offshore
company facilities), the application should still be responsive. This might require setting up
additional application servers at a remote site. This in turn might require database replication
or distribution as well as application specific data partitioning. At least a rough technical
concept is required for this scenario.

2.9. Hosting and IT Cybersecurity

2.9.1. General Remarks

The provider is expected to comply with modern safety and security standards for data
centers and with Continentals internal IT policies:
• ISO standard IEC 27001 for Information Security
18
 o Redundant utilities, especially uninterruptible electricity for the data center itself as
well as all racks and components,
o Fire alarms and automated distinguishers, secured air handling and air conditioning,
o Access control and surveillance for all personal working in the data center.
• European Directive 95/46/EC (Protection of individual, personal data)
o For Germany: German Data Protection Law (“Bundesdatenschutzgesetz”)
• Auditing Standards: SAS70, SSAE 16
• Anti-Virus Protection
• Continental’s Security Guidelines and Manuals for
o Security Patch Handling Regulation (M60.02.11)
o Security Guidelines for Databases (M60.02.05)
o Patch Management for Databases (M60.02.05.1)
o Password Regulation (M60.02.01)
o Backup and Recovery Security Regulation (M60.02.08)
Continental initially requires that the application will be either hosted in a data center of the
provider’s choice or hosted at Amazon Web Services or within Microsoft Azure. In all cases,
the data center must fulfill EU data protection requirements, which means to be located
within the European Community or Switzerland. The provider is responsible for providing a
full-managed hosting service under its control. Beneficial use of synergies like Continental
dedicated line to AWS Frankfurt should be considered in case an on premise approach is
needed.

The peak bandwidth, network performance and content delivery must be sufficient to serve
all of Continental’s sites worldwide.
The sizing of the physical components should be initially planned on experiences made by
the provider and according to the given quantity structure. Whenever the current sizing
does not fit longer to the actual utilization, all components must be scalable with a minimum
of downtime interrupts, in best case dynamically during operations (cloud-optimized
application). A flexible up-scaling mechanism is seen as part of operations and monitoring.
The provider is fully responsible for managing and securing storage capacities. This must
be done in a flexible, redundant and extendable way without interrupts during normal
operation. Monitoring must prevent from sudden disc space overflows.

2.9.2. Data Seggregation

Continental’s IT security will only accept hosting solutions where measures are in place to
strictly separate Continental’s data from other clients.

19
 Components that are shared with other customers (e.g. main application core modules)
should be mentioned in the documentation as part of the architectural system overview.

Furthermore, the documentation should explain how the partner ensures that all clients’
data are kept separate at all times.

2.9.3. Test- and Development System

Beside the production environment, there might be an “on-demand” need for a test
environment whenever a major release is available, a certain customization has to be
developed, tested and approved or for integrating into other services.

This test environment should reside in the same network and data center environment.

In case a 2-tier-landscape with a test/development-system and a productive system can not

be offered or is not recommended from your side, please specify how your best practice for
testing of configuration and integration looks like.

It is expected to provide a detailed documentation for backup and recovery of production

data.

2.9.4. Back-up and Recovery

The back-up documentation is seen as part of the service. It must be updated when there is
a need for and should address the following questions for all machines and application
types mentioned in this document:
• What kind of backup – full, incremental, differential – will be performed?
• How often will backups be performed?
• What kind of backup verification is in place?
• What kind of backup media will be used?
• When and how will backup media be reused?
• Estimated time needed for backup and even more important for restore operations
• How is secure transfer of data to the backup media guaranteed?
• Which personnel will have access to backup media for restores? How are backup files
protected against misuse?
• What happens when the backup system itself fails?
• How will disaster recovery be performed and what policies will apply here?

20
2.9.5. Licensing of Support Tools

If needed, Continental will provide licenses for VPN access and communication purposes
(e.g. WebEx and other communication tools).

Continental will not provide any licenses for products that maintain or support the software
service itself (e.g. monitoring tools, anti-virus, SQL Management Studio et al.).

2.9.6. Virus Protection and OS Updates

All client and server hardware involved on providers side have to be monitored for viruses
and other threats.

The provider is free to decide on the Anti-Virus software as long as the protection is always
up to date and working. All systems need to be kept up-to-date with security or operating
system patches and updates.
In case of server-side patches or updates, the future partner is expected to work closely
together with Continental to ensure that the updates or patches does not interfere with daily
operation.

Continental expects a description of processes applicable to patching as part of the service

design (maintenance cycles and schedules).

Continental commits that all server and clients, provided and used by Continental are
antivirus protected using McAfee VirusScan Enterprise & AntiSpyware Enterprise 8.8

2.9.7. Data Life Cycle

Please specify how long data are archived on the back-end system, how data can be
deleted and how data be provided in case of a contract termination.

It is required that all current country specific laws to store, maintain, archive or delete can
be fulfilled.

21
2.9.8. Data Protection

Please describe how the compliance with relevant data protection requirements of all
countries in scope is ensured. This includes details, how the new data protection law in
Russia with its obligation to store personnel data of Russian citizens only on servers in
Russia, is fulfilled.

In case any subcontractors are involved by the providers (e.g. for hosting, development
support e.g.) please state following data of the committed subcontractors:

1. name and e-mail

2. physical address
3. description of the scope and portions of the work the subcontractors will perform.

Disclosure where the main and backup data centers are and naming of the full physical
address is required. Continental strongly prefers that any data storage (data center) shall be
within the EU, ideally in Germany. Please confirm that data storage is only taking place in
these locations. Furthermore Continental needs to know, if support, hosting and data center
operations (including remote support) carried out within the EU or Germany?

Due to the fact that documentation of implemented measures is crucial to proof compliance
please provide respective written documentation (e.g. operations manual)

Please provide your security concept or if available certifications like ISO 27001, SAS70,
etc. which state that you have implemented sufficient technical and organizational security
measures

Please prove that your employees were informed about data confidentiality according to all
applicable laws (e.g. § 5 BDSG (Bundesdatenschutzgesetz))

If relevant: is also outside the EU (this also applies for involved subcontractors) an
adequate level of data protection (e. g. through EU standard contract) ensured?

Is there a data protection officer, who is available as a contact person towards the client
regarding all aspects of data protection at the provider and its subcontractors? Please
provide references.

22
 Are regulations regarding data protection, business secrets part of the contract? Please
provide references resp. explanation.

Is the duration of the processing, storage and deletion of the data accurately defined?
Please provide references resp. description.

Does the data ownership in any case stay within Continental? Please provide references
resp. explanation.

Continental needs the confirmation that organizational structures, procedures and tasks are
documented (e.g. operations manual).

3. Project Approach, Timeline and Other Details

3.1. Project Management

The Conveyor Belt Group will be responsible for overall project management, working in
close collaboration with the provider. The provider has to nominate an overall project
manager, being in charge for the timely delivery of agreed objectives, the number and
appropriate availability of respective resources and external budget controlling.

The project will incorporate milestone gates / checkpoints as a means to ensure quality.

The estimated timeline is shown below:

23
3.2. Training
The implementation partner is expected to deliver product trainings to the project core
team members. Target is to facilitate with the best practices of the market to the
Continental team to collaborate in the most effective way in the design and configuration
phase. As well, to enable Continental’s system administrators to configure back-end and
24
 front-end independently of the provider to the highest possible degree as soon as the
project has gone live.

In general, the implementation partner is expected to collaborate with Continental in the set
up of an appropriate training concept, as far as end user training is needed.

3.3. On-site Support during first Go Lives

It is expected that on-site support of the provider is guaranteed for the Pilot implementation
in Northeim Germany. Further support can be done via remote.

4. SPECIFICATIONS

4.1. Term of Contract(s)

1.1.1. The contract term will begin on the effective date of the contract and will expire on
the completion of up to five years. Continental will have the option to renew or extend
the contract for a period up to two years as necessary to complete the missions of
this procurement at a price agreed to by the parties. The Contract shall be governed
by and construed in accordance with the law of the Federal Republic of Germany
without giving effect to the conflicts-of-law rules hereunder.

1.1.2. The payment term of the contract will be 90 days.

25
4.2. Instructions for Submitting Proposals
All proposals should be structured in a set of documents as described below:
Executive summary
– Attachment A: Supplier Questionnaire mentioning software requirements
– Attachment B: Pricing Template
– Attachment C: Framework Agreement
– Attachment D: Sourcing Guidelines
– Attachment E: Process Map
– Attachment F: Design Draft – Data Entry
– Attachment E: Draft web based Dashboard

The detailed requirements for each of the above mentioned sections are outlined in
the attachments.

4.3. Detailed Response Requirements

Executive Summary. The provider is asked to provide an executive summary of the response,
including cost information, asserting that the provider is providing, in its response, all of the
requirements of this RFP. The Executive Summary must not exceed three pages and should
represent a full and concise summary of the contents of the proposal.

Attachment A: Requirements catalogue. Provider is asked to provide accurate information on

which of the listed requirements (core or otherwise) can be fulfilled by the offered Solution. This
information can be challenged in the presentation / system demo workshop by the
representatives of Continental.

Attachment B: Pricing Template. The provider is asked to provide pricing information in Euros
(€) in the format of the pricing template.

Attachment C: Framework Agreement. Continental AG has provided an empty template. The

provider is asked to include own Framework Agreement document into the template.

26
27