sony pictures entertainment sap hcm rfpbusiness... · web views to whether or not it intends to...

Confidential

CORPORATE PROCUREMENT SERVICES

Request for ProposalSony Pictures Television Networks

EMEA MediaCentre

Date Issued: March 8th, 2013

Confidential

Table of Contents

1.0 Introduction and Overview......................................................................................31.1 SPE Business Overview............................................................................................31.2 Project Background.................................................................................................32.0 Instruction to Bidders..................................................................................................42.1 General Guidelines.................................................................................................42.2 RFP Process Time Line..............................................................................................52.3 Contact Information................................................................................................62.4 Required Information..............................................................................................62.5 [Evaluation Criteria, if applicable]............................................................................62.6 Bidder Q & A and Check-In.......................................................................................72.7 Bidder Oral Presentation.........................................................................................72.8 Disclaimer...............................................................................................................72.9 Conflict of Interest...................................................................................................73.0 Previously Communicated changes to MediaCentre RFP..............................................93.1 Communicated August 8th, 2012..............................................................................93.2 Communicated February 14th, 2013........................................................................104.0 Guiding Statements...................................................................................................125.0 Detailed Requirement Statements.............................................................................175.0 Reference Architecture..........................................................................................186.0 Appendices................................................................................................................20Appendix A............................................................................................................................21Appendix A-1 – Outline for Response.....................................................................................22Appendix A-2 - References.....................................................................................................23Appendix A-3 – Pricing Proposal.............................................................................................24Appendix A-4 – Resource Loading Schedule............................................................................25Appendix B – Information Security Questionnaire..................................................................26Appendix C- Sustainability Questionnaire...............................................................................27Appendix D – Supplier Diversity.............................................................................................28Appendix E – Questions to Bidders [If needed].......................................................................29

ConfidentialityThis information is considered CONFIDENTIAL and PROPRIETARY to Sony Pictures Entertainment Inc. This information is intended only for the person or entity to which it is addressed. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.

2013 Sony Pictures Entertainment Inc.All Rights Reserved 2 of 40

Confidential

1.0 Introduction and Overview

1.1 SPE Business Overview

In over 60 international locations, Sony Pictures Entertainment (“SPE”), based in Culver City, California, is a worldwide leader in creativity and innovation. Backed by the power of Sony, one of the world’s most recognizable and respected brands, SPE’s global operations encompass motion picture production and distribution; television networks, production and distribution; DVD acquisition and distribution; operation of studio facilities and development of new entertainment technologies. SPE is known for franchise films such as the Spider-Man and Men in Black series along with others such as, Da Vinci Code, Surf’s Up, The Social Network, 2012, Resident Evil, Superbad, Memoirs of a Geisha, Bad Boys (I and II), Jerry Maguire, and The Pursuit of Happyness. SPE also owns and distributes a library of over 3500 films and a significant number of television programs. Additionally, SPE produces a large number of network and non-network television programs throughout the world. SPE also has 8 branded television networks and maintains significant ownership of many other networks throughout the world.

1.2 Project Background

[Provide details]

1.3


Confidential

2.0 Instruction to Bidders

2.0 2.1 General Guidelines

a) All information requested in this RFP package is required on or before [Date & Time]. Please be as thorough as possible in providing the information requested in the RFP package as this will assist us in the evaluation process.

b) We require that your company indicate via email to [Name] by [Date & Time] as to whether or not it intends to submit a proposal response to this RFP package.

c) [Any questions you have pertaining to this RFP package should be submitted via e-mail only to [Name] by [Date &Time]. SPE will host a Bidder Conference on [Date & Time] to address these questions. This Bidder Conference will also provide the opportunity for bidders to pose additional questions to the SPE team to be answered during the Bidder Conference. Further information regarding this Bidder Conference will be provided under separate cover at a future date to be determined.OR[Any questions you have pertaining to this RFP package should be submitted via e-mail only to [Name] by [Date &Time]. All questions will be answered via email and made available to all bidders who have elected to participate in the RFP process.

d) All pertinent information for preparing a bid is contained within this RFP package. Failure to review all materials fully and carefully will not protect a bidder that will be submitting a proposal from full responsibility for the services to be provided. All responses to the RFP package should be included in the proposal. A bidder’s proposal to SPE shall be assumed by SPE to be a fair and accurate representation of all costs applicable to the proposal submitted by the bidder.

e) The proposal must be valid for [TBD] from the date of submittal to SPE. No corrections or modifications will be accepted without prior written consent from [SPE Contact name] via e-mail only.

f) Exceptions to any part of this RFP package relating to your proposal must be clearly stated in a letter accompanying your proposal. Any ideas, suggestions or alternate proposals you may wish to submit that may be of mutual advantage are welcome and will be considered only upon your compliance with the RFP package.

g) The preparation of all proposals shall be at the expense of the bidder submitting the proposal.

h) Bidders shall not take advantage of any apparent errors or omissions in the RFP documents provided by SPE. In the event that any errors or omissions are discovered which can affect pricing, Bidders shall notify SPE’s primary representative immediately via email.

i) Each proposal shall: (1) show the full legal name and business address of the bidder submitting the proposal, including its street address if it differs from its mailing address, (2) be signed with the usual signature of the person, or persons, authorized to bind the bidder submitting the proposal, and (3) be dated. A proposal submitted by a partnership or joint venture shall list the full name of all partners or joint ventures. The name of each signatory shall be typed or otherwise clearly imprinted below each signature. In the event that verification is requested by SPE, satisfactory evidence of the authority of any signatory to act on behalf of the bidder submitting the proposal shall be promptly furnished.


Confidential

j) In addition to the points outlined in item “h” above, each proposal shall include all the information as requested in Appendix A [and Appendix B, if applicable]. A proposal submitted without including the information outlined in Appendix A [and Appendix B, if applicable] will not be accepted for consideration.

k) SPE reserves the right to award one or more contracts on the basis of proposals received. SPE also reserves the right to accept or reject your proposal in whole or in part. If all or any part of your proposal is accepted, a contract may be submitted to you for execution. SPE reserves the right to make a contract award without written or oral discussion with any bidder submitting a proposal. SPE reserves the right to decide not to make a contract award to any bidder submitting a proposal.

l) SPE reserves the right to modify any provisions or parts of the RFP documents at any time before expiration of the original RFP submission due date. The closing date set forth in this RFP also may be extended at any time by SPE before the original RFP Bidder submission due date.

m) SPE reserves the right to schedule a site visit both prior to, and subsequent to, the proposal submittal due date of this RFP package to assess facilities, staffing, infrastructure and any other areas deemed pertinent to this RFP process.

2.1 RFP Process Time Line

SPE has established the following estimated time line for the completion of this RFP process:

Description of Activity TimeframeRFP package is released to potential bidders for bid Final date for potential bidders to declare their intentto participate in the RFP process[Final date to submit questions or requests for clarification, if applicable][Bidder’s conference for clarification of RFP package, if applicable] Final date for receipt of proposals by SPE[Bidder Oral Presentations, if applicable][Estimated project start date, if applicable]

Late responses may be disqualified.For your proposal, SPE requires the following:

[# of hard copies] of your proposal via Federal Express (or similar service) or hand delivery to:Sony Pictures Entertainment Inc.10202 W. Washington Blvd. Culver City, CA 90232Attn: [Name & Location]

Electronic copy to [Name & Email Address]. Any additional materials or attachments detailing any other relevant information

specific to your proposal, which you deem necessary and which was not initially requested within the RFP package.


Confidential

2.2 Contact Information

To ensure consistency of communications, SPE and bidders participating in the RFP process will manage communication and contacts through the designated contact(s) below.

2.2.1 SPE Point of ContactTo ensure fairness throughout the RFP process, please submit all questions with regard to this RFP package to the designated SPE representative. Contacting other parties within, or associated with SPE may result in disqualification from the RFP process. Only information received from the designated SPE representative should be considered valid and binding. For the purpose of this RFP process, please direct all questions via e-mail only to the following individual.

[Contact Name] Telephone: [Telephone Number]Sony Pictures Entertainment Fax: [Fax Number]10202 W. Washington Blvd. Email: [email Address][Suite Number]Culver City, CA 90232

2.2.2 Bidder Point of ContactSPE encourages all bidders electing to submit a proposal to involve their senior management with decision-making authority, as well as the account management team most likely to be dedicated to SPE, in both the RFP process and any subsequent meetings/discussions. Please identify within your proposal the primary individual contact name, and a secondary/backup contact name for your company during the RFP process who is/are empowered to field any questions or further requests from SPE as they may arise. In doing so, please also provide in your proposal the following information pertaining to these individuals:NameCompanyTitleAddressTelephoneFaxE-mail address

2.3 Required Information

Bidder is to provide a comprehensive response in accordance with the information requested in the RFP package including all the appendices under Appendix A [and Appendix B, if applicable].

It is SPE’s preference that the bidder responses not include general marketing material. However, should bidder choose to include such information it must be limited to no more than five pages.


Confidential

2.4 [Evaluation Criteria, if applicable]

The submitted proposal, or proposals, deemed by SPE to be the best overall will be based upon our evaluation of all elements of each of the submitted proposals. While the following areas are not intended to be all inclusive and should not be viewed as such by those bidders submitting proposals, they do reflect some of the criteria to be used by SPE the proposal evaluation process.

Project approach and methodology Project team qualifications Pricing Credentials and prior experience References from current and previous customers Company’s financial status

2.5 Bidder Q & A and Check-In

2.6 Bidder Oral Presentation

As previously mentioned in the above RFP timeline table, SPE anticipates holding oral presentations with selected bidders during the week[s] of [Date] [and Date]. Further information regarding the final scheduling and format for these oral presentations will be provided under separate cover at a future date to be determined.

2.7 Disclaimer

This RFP process does not commit SPE to any specific course of action. All costs associated with the preparation and submission of a proposal shall be borne solely and exclusively by the bidder submitting the proposal.

2.8 Conflict of Interest

Bidder hereby represents and warrants as to itself that it has no Conflict of Interest. “Conflict of Interest” shall mean that Bidder has a relationship with an employee, officer, director or board member of SPE, its affiliates or subsidiaries that could give rise to a claim of a conflict of interest on the part of the employee, officer, director or board member of SPE, its affiliates or subsidiaries. Relationships that are considered “Related Party” include but are not limited to:

Relative by blood or marriage (for example, Bidder and SPE employee are spouses, parent/child, siblings, in-laws, etc),

Friend, Investor, Shareholder, Owner, Co-owner, Partner in business,


Confidential

Consultant, or Any financial relationship which may allow the SPE employee, officer, director or board

member to profit from Bidder’s work for SPE.The Bidder shall disclose any and all Related Party relationships with any employee, officer, director or board member of SPE, its affiliates or subsidiaries as part of its proposal. Subsequent to Bidder submitting its proposal, Bidder shall promptly inform SPE of any change in status, or new relationships, during the course of this RFP process which results in Bidder becoming a Related Party.


Confidential

3.0 Previously Communicated changes to MediaCentre RFP

3.0 Communicated August 8th, 2012

Section C.2.1 – Business aims and objectives

Change: Primary MC equipment facilities to be hosted at an external datacenter, location tbd, in the greater London area, not at Golden Square.

Production operations will be located at Golden Square along with any required equipment to support this functionality

MC will not be supporting a Disaster Recover TV channel playout operation.

Section C.2.6 – MediaCentre - Physical environment

Change: Central Technical Area (CTA) will be remotely located at an external datacenter, location tbd, the greater London area, not at Golden Square.

Note: Support of CWM QC and other MediaCentre systems should be accessible at other datacenter location.

Remove: TV channel playout monitoring/DR playout suite: remove from specification.

Section D.1.2 – Audio-Video (AV) signal routing / processing

Change from: Sources: VTR outputs (three installed plus one for future expansion)Domestic satellite / cable IRD outputs (to be free-issued by SPTN) (two)

(including signal conversion equipment as necessary)

Change to: Sources: VTR outputs (one installed plus one for future expansion)Domestic satellite / cable IRD outputs (to be free-issued by SPTN) (one)

(including signal conversion equipment as necessary)

Section D.1.3 – AV multi-viewer mainframes

Change: No multi-viewer mainframes required Section D.1.6 – Communications / talkback

Change: No Communications / talkback system is required

Section D.3 – TV channel playout monitoring / DR playout control suite

Change: Remove TV channel playout monitoring/DR playout control suite.


Confidential

Section D.4.1.1 – VTR ingest / outgest provision

Change from: The respondent shall make provision in the CTA and install a total of three videotape transports (VTR) – 2 x Digital Betacam + 1 x HDCAM SR – to be free issued by SBTNB.

Change to: The respondent shall make provision in the CTA and install a total of two videotape transports (VTR) – 1 x Digital Betacam + 1 x HDCAM SR – to be free issued by SBTNB.

Additional information required from respondent:

• Footprint size & number of racks at the primary London based datacenter location to support MC

• Footprint size & number of racks at the Golden Square/London, Budapest and Madrid locations to support production operations

• Power consumption totals and per rack to support equipment at the primary London based datacenter location to support MC

• Power consumption totals and per rack to support equipment at the Golden Square/London, Budapest and Madrid locations for production operations

• Network design and interface detail at primary London based datacenter location for the interconnectivity to the SPTN WAN to support production operations at the Golden Square/London, Budapest and Madrid locations

3.1 Communicated February 14th, 2013

Section D.2 – Traffic Area

Change from: The respondent shall provide the following for this facility:Two supervisor technical desksSix traffic operator desks

Change to: All desks will be supplied by SBTNB via free issue. Please retain monitors, monitor arms, and other accessories.

Section D.4 - QC/Version edit suites

Change: Eliminate all desks & furniture (2 x super / 4 x ordinary). All desks will be supplied by SBTNB via free issue. Please retain monitors, monitor arms, and other accessories. Change: Eliminate all Apple/MacPro computers (qty 4).


Confidential

Retain I/O breakout cards.MacPro items will be supplied by SBTNB via free issue.

[Provide details]


Confidential

4.0 Guiding Statements

[Need to decide on proper title for this section]

Based on extensive discussions with the Sony team in the various operational and technical groups, these statements were created to clarify and amplify the workflow diagrams and requirements previously communicated in the original RFP.These statements supersede previous information, in case of conflict. The statements are presented in categories for organizational purposes and should not be considered in a priority or preference order.

[BEGIN insert of guiding statement]

MediaCentre Team Statements

Content ID/MetadataMetadata

Programme records will originate and be registered through the determined MDM system. The MDM system will hold the master record to be used downstream for any systems in the broadcast workflow, where required.

Alpha records will require registration in the MDM system, but depending on workflow, the actual creation may be initiated outside of the MDM. The MDM system will hold the master record for alphas which can be used downstream for any broadcast systems where required.

Pending further analysis on alpha creation workflows, the MDM system may require a mechanism for "syncing" alpha records with downstream systems in the broadcast workflow, as a contingency.

The MDM system will be the source of all descriptive metadata associated to the programme or alpha records.

The MDM system will master the programme, alpha, territory, language and channel records.

All scheduling and programming detail will remain within the existing broadcast systems.

Content Organization

Versions records, as currently defined by the Harris Systems, will not be stored as a content level within the MDM system or within the Media center.

Versions will remain a scheduling system concept, but will be translated within the interface, as needed, to interact accordingly with the media center.


Confidential

Versions, as defined by the Harris Systems, are not synonymous to the SPE definition of Alpha. Versions, at this stage of requirements, appear to be more closely related to the concept of order or profile.

Inventory within the media center will be organized in a programme>alpha>component>asset hierarchy. With an additional requirement to “group” conformed components. Pending confirmation by the core EMEA team, the Media Center will use a similar, but not necessarily identical, definition of alpha as defined by SPE.

The media center will require some type of interface, through Vision or BMS, for programmers and schedulers to query existing inventory and/or submit orders for the purpose of linear transmission. This interface may include the ability to select an alpha, territory, language, and channel as criteria for inventory search or order submitting.

Promotional assets will be stored within the media center as another alpha and can associated to any level of the programme hierarchy.

The media center will likely store the original ingest master as a version within inventory, yet not to be used for direct transmission.

The Media center will need to include supporting materials/ancillary assets within its inventory design. Design tbd.

In its best case, the Media Center will have direct integration to a centralized Rights Management System, where linear and non linear rights will be sourced. As a contingency plan, Media Center may need the ability to manually enter non-linear rights directly in the MAM. Linear -Rights will still be retrieved from Vision/BMS, but may not necessarily be entered in Vision/BMS itself, pending Rights Management solution.

Content Identification Due to the heavy reliance of smart numbering in the scheduling and playout systems,

the media center project will require unique content identification across all levels of the content hierarchy as well as maintenance and mapping to the existing identifiers already established in the current workflows.

Infrastructure[Placeholder]

Integration The majority of requirements for integration with the Linear Scheduling Systems are

defined in the original RFP. The first phase of MediaCentre does not include the requirement to enable integration

with Non-Linear Scheduling, but MediaCentre should be able to upgrade or enable capability to interface with such a system in the future.

The first phase of MediaCentre does not include the requirement to enable integration with an Ad Sales System, but MediaCentre should be able to upgrade or enable capability to interface with such a system in the future.


Confidential

MAM Requirements• The MAM will need to be flexible enough to receive a number of different file formats

convert these into the Sony house format for use throughout the system.• The MAM should be flexible enough that new hardware devices can be integrated with

minimal custom interfacing• MAM will integrate with AD/Sony IDM system to provide access control to all users. • The MAM will manage the delivery and packaging of video, audio, subtitles, images, pdfs

and text files for delivery to client profile locations• The MAM will integrate with Cerify for file based QC, with results being accessible

through • The MAM will integrate with Aspera and other delivery solutions to provide a secure,

traceable and accelerated delivery of assets to client end points• The MAM will have the ability to initiate an ingest workflow without being initiated by

the agreed system• The MAM will have the ability to create content to specific file formats needed for

delivery to linear playout services and to VOD services for linear operators platforms. • The MAM will have the ability to restrict delivery of content if certain key• The MAM should provide detailed logging of every user action and process undertaken

by the system and allow access to this through the systems reporting infrastructure• The system that will initiate ingest workflows and push rights and other key data into

the MAM is yet to be decided and needs agreement• The MAM should provide the ability to ingest content from multiple geographic regions

Operations[Placeholder]

Program Acquisition

The Program/Title Records creation process in the MediaCentre will typically be triggered by the scheduling of the program by any of the Scheduling Systems (Today: Vision, BCM, and possibly Provys). The Scheduling System will receive all record creation information from GPMS/MDM directly. All program create and update data for the MediaCentre will come directly from GPMS/MDM.

MediaCentre will be able to manually lookup and create a program record in the MediaCentre from GPMS/MDM without being triggered by the Scheduling System via a direct interface to GPMS/MDM for program/title data.

The MediaCentre will receive any critical dates for deliverable completion or delivery from either a Linear Scheduling System (Vision, BCM, and possibly Provys) or a Non-Linear Scheduling System (Vision, TBD…)


Confidential

The MediaCentre will be able to accommodate the availability of editorial restrictions data in future releases (this workflow will not be implemented in phase1)

The MediaCentre will have the automated capability to merge/replace program/title level records if sent a replacement ID (ex: in the case of a duplicate)

The MediaCentre will have the capability to receive ongoing updates from GPMS every 5 minutes

The MediaCentre will be able to store and search across program/title AKA’s and localized titles (important in the case of program name changes or for multi territory acquisitions)

The MediaCentre will have the ability to persist N number of foreign program/title keys from GPMS and will be able to match inbound content utilizing foreign key cross reference (focus on EIDR ID)

ContentID Track overlapo MediaCentre will be able to receive Alpha records from GPMSo MediaCentre will be able to register Alpha records in GPMS

Reporting• MediaCentre will allow users to create custom reports without requiring sysadmin or superuser rights.• MediaCentre will make reporting data available to other systems to allow external analysis and reporting if desired.

Security• The systems comprising MediaCentre will require testing for proper code security,

interface design, and network access, during design, before launch, and on an on-going basis.

• A comprehensive security patching and updating system is needed for the systems comprising MediaCentre.

• MediaCentre will meet requirements for each subsystem in line with Sony GISS and GISP standards.

• Each group within the project will identify security threats and scenarios which affect the confidentiality, integrity and availability (continuity and DR) to the Media Centre system components and workflows and work with the Security lead to address them.

• All vendors will be asked to identify areas where they will be layering in security to ensure the overall system remains secure at all layers and addresses security threats relevant to Media Centre and its content.

• Specific security consideration will be given where components are internet facing or house personal information, considerations such as secure encrypted protocols, watermarking and encryption at rest will be considered.

System Architecture


Confidential

[Placeholder]

Tech Specs[Placeholder]

VOD/Non-Linear• MediaCentre will have the capability to generate, package, and transfer traditional VOD

content, intended for set-top boxes.• MediaCentre will have the capability to incorporate additional metadata (title

information, delivery requirements, etc.) from other systems to the extent necessary to generate proper VOD packages.

• MediaCentre will have the capability to generate mezzanine level assets for use by other Sony groups such as OTT, Crackle, DADC, etc. and/or storage in other library systems.

• MediaCentre will not be expected to generate final delivery content for OTT type uses.• MediaCentre will not be expected to handle non-linear advertising.• While a non-linear scheduling system is an important idea that deserves further

consideration, it is not part of the MediaCentre project.• MediaCentre will expose interfaces to OTT service automation to allow for querying of

asset data and requesting delivery of assets• MediaCentre will standardize an asset identification method• MediaCenter will standardize a subtitle delivery format • Workflows

[END insert of guiding statement]


Confidential

5.0 Detailed Requirement Statements

[Need to decide on proper title for this section]

Based on extensive discussions with the Sony team in the various operational and technical groups, these statements were created to communicate specific system requirements.These statements supersede previous information, in case of conflict. The statements are presented in categories for organizational purposes and should not be considered in a priority or preference order.

[BEGIN insert of detailed statements]

Integration

The majority of requirements for integration with the Linear Scheduling Systems are defined in the original RFP.

The first phase of MediaCentre does not include the requirement to enable integration with Non-Linear Scheduling, but MediaCentre should be able to upgrade or enable capability to interface with such a system in the future.

The first phase of MediaCentre does not include the requirement to enable integration with an Ad Sales System, but MediaCentre should be able to upgrade or enable capability to interface with such a system in the future.

Infrastructure MediaCentre will have an interface to the EAGL/DMR API

[include API spec]

MAM Requirements Subtitles and dubbed audio will be available in the MAM for use by OTT/VOD

systems. The MAM will be able to insert a logo graphic into a VOD deliverable file. Proxy video should include all audio tracks. MAM will log every action performed by a user and have this data available to

superusers for reporting purposes. QC failed distributor files will be held in a Quarantine Area until a replacement

arrives.


Confidential

The MAM will have the ability to accept and display usage windows for various languages and locations.

Capability to Clip Export by users needs to have varied levels of rights. Tech Specs MediaCentre will not apply DRM to content in the VOD process. MediaCentre should be able to handle subtitle/captioning properly for both 4x3

and 16x9 aspect ratio content. QC profiles should be able to be created and edited without interrupting QC

work. MediaCentre will have the ability to utilize any capability or codec within the

transcoding subsystem as part of a profile.

Workflows Workflow templates will need to be created and modified by superuser/

sysadmin without vendor support. VOD profiles (including delivery location/file tech spec) will need to be created

and modified by superuser / sysadmin without vendor support. MediaCentre will be able to report which items have been successfully delivered

to the Playout partner or Non Linear platform. The workflow will have no reasonable limit to the number of additional assets

that can be associated to a primary asset after has been ingested in to the system.

MediaCenter will be able to prioritize processing of content on multiple criteria such as transmission date, license start, distribution partner, etc.

Media will be available to users, such as the Promo group, immediately upon ingest, even without QC.

MediaCentre will have a process to ingest content even if a record placeholder from the scheduling system has not been created in advance.

MediaCentre will have the ability to manually override any ‘wait’ condition in a workflow.

MediaCentre will clearly identify to users what stage an asset is in throughout individual workflows

[END insert of detailed statements]


Confidential

6.0 Reference Architecture

[insert of detailed statements]

6.1 Media Centre Project – Reference Architecture

The Reference Architecture outlines the primary functional components and interfacing applications for the Media Centre.

Reference Architecture Diagram

Third Parties

Media Centre

London – Golden Square

QC/Edit

OperatorsOperators

Distributors(Various)

Distributors(Various)

SERVICES LAYERCommon platform that provides monitoring, routing, translation/transformation, protocol mediation, and message queuing

Media Asset Management

File Mgmt Metadata Mgmt

Ingest

Storage Mgmt/HSM

Replication/DR

Search

Content Processing

Standards Conversion

Wrapping

Transcode

Technical QC Content Formatting

Checksum

Graphics

Madrid

Budapest

PromosPromos

OperatorsOperators

Audio

Package Assembly

Supporting Material Acquisition

Metadata Transformation

File Naming

Delivery

Signiant

Aspera

FTP/SFTP

AssetsAssets

WORKFLOW MANAGEMENTOrchestration of Business Process and Content Processing Workflows (i.e. Ingest, QC, Content Processing, Delivery)

Assets

Assets

AssetsMetadata

Playout

Non -Linear

Interfacing Systems

IngestAsset

IngestMetadata

IngestAsset

IngestMetadata

Assets

Assets

HARRIS VISION

(SCHEDULING)

HARRISLANDMARK

(AD SALES)

HARRISBROADCAST MASTER(SCHEDULING, AD SALES)

NETGAIN(BUSINESS

INTELLIGENCE)

GPMS(TITLE/ALPHA METADATA;

RIGHTS)

EAGL(SUPPORTING MATERIALS;

ARCHIVE)

Metadata

Metadata

Master Data Management

DistributorProfiles

DistributorProfiles

ScheduleData

ScheduleData

Inventory MetadataInventory Metadata

PackageMetadataPackage

MetadataProgramme

/AlphaProgramme

/AlphaClient Master

ProfilesClient Master

Profiles

SAP &FINANCIALS

MANAGEMENT

Post HousesPost HousesAssets

FARMERS WIFE(FACILITY MANAGEMENT)

Future

CINESHARE (HISTORICAL DROP-POINT

FOR DISTRIBUTORS)

Technical Logging

LocalisationLocalisation

Security

IDM(SPE COMMON

AUTHENTICATION)

Metadata

User Interface

Vendor Portal

Operations Portal

Delivery Confirmation

Utility Services

Event Management

System Logging

Exception Management

Notification

RemoteIngest

RemoteIngest

PROVYS(SCHEDULING)

Reporting

INTERFACESIngest Inventory DeliveryOrdering/Request Search Programme Metadata

Reference Architecture Guiding Principles

A key requirement of the Media Centre architecture will be its ability to be flexible to not only meet the currently known means, but also to be able to scale in functionality to meet future needs – both short and long term. A key aspect of short term flexibility would ideally be accomplished through system configuration that can be accomplished by Sony Picture Networks Operations staff and not through customization requests to a vendor.


Confidential

Examples of the Flexibility include, but are not limited to the following:

Workflow creation/modificationo Changing the “Ingest” workflow/pipeline as is default in their “off the shelf”

solution to meeting our needs (i.e. drop boxes, configurable generation of proxies, etc.)

o Adding new workflows to move content after Ingest for QC/Edits, Localisation, etc.

Deliverables/Output configurationo Creating/updating technical specifications/profiles that define how the MC

processes and then deliveries content

Asset Structure and Metadata configurationo Changing the metadata structures and configurable fields associated to

assetso Creating hierarchies or organization of assets that meet our needs

Bidders are requested to explain how our Operators could accomplish the above flexibility with the proposed solution as well as call out when vendor help would be necessary.

Reference Architecture Interfaces and Common End-points

The Media Centre should be build upon/leverage a platform that is service-oriented in design and, thus, provides open API access. Additionally, when presenting interface to external systems, it is desired that the Media Centre expose generic interfaces vs. specific integrations (i.e. Scheduling Interface vs. Harris Vision Interface). Below are general considerations as well as the six major interfaces expected of the Media Centre that should facilitate the specific system integrations defined in the RFP.

General Conceptso General Service Interfaces as well as access to a detailed API that

exposes all of the system functionalityo API access to service queue visibility for processing (messages, services)

Ordering/Request (bi-directional)o Create, update, cancel based on call from external system (e.g.

Scheduling System(s))o Defines programmes to be delivered to a client (such as playout, VOD,

OTT, etc.) by a specified due dateo Asynchronous interface with a callback mechanism to update status.

Searcho Ability to search data within the Media Center across several categories

of data Asset inventory


Confidential

Programme metadata Order/request data

Programme Metadatao Create, update, deactivate programme metadatao Including content hierarchy (i.e. Programme-Episode) as well as

descriptive data (i.e. synopsis, talent) in various languages

Ingesto To remotely trigger ingest of assets + metadata

Inventory (bi-directional)o Create placeholders/shells to represent expected arrival of assets to meet

scheduling needso Update asset metadata or status (i.e. Available, Deactive)o Asynchronous interface for status callback to Scheduling system(s)

Deliveryo Status for/from the tools on status (percentage progress, success/failure)

Reference Architecture Definitions

1. Media Asset ManagementProvides the foundational services for the management of files and metadata about the assets within the Media Centre (including Programme/Alpha metadata interfaced into the Media Centre). It is likely that in a Phase 2 these Services will be distributed for disaster recovery/business continuity or performance reasons, perhaps across geographies, so this should be factored into the proposed architecture.

1.1. File ManagementAlso can be referred to as the “Vault Services,” the File Management service(s) provide the digital file analog to the management of physical assets. It coordinates the formal storage and movement of files around major storage pools in the Media Centre. The File Management Services will need live visibility into Hierarchical Storage Management (HSM) storage tiers/locations (i.e. what storage media it is on and where it is?) for operational support requirements.

Priority queuing will be required for this service to manage load and to contribute to stability and meeting performance requirements.

1.2. Metadata ManagementThe repository where metadata is stored and updated within the Media Centre for use in digital file inventory management/processing and business/title metadata for packaging

1.3. Ingest


Confidential

Services facilitating the process of getting components and their metadata verified and QC’d before entering the Media Centre. In that process these Services will often be orchestrated with Content Processing Services (e.g. automated technical QC, checksum calculations) and provide additional validation logic.

1.4. Technical LoggingToolsets that allow the playback of master files and, preferably, their frame-accurate proxies for the purpose of capturing segment metadata (e.g. time code in and out points for areas such as bars/tones, commercial blacks, logos, program). Ideally, these tools would be paired with a content identification system that would be able to pre-process the video and provide suggestions for the operator to confirm/complete.

1.5. Replication Services (for Distributed Computing and Disaster Recovery)Out of scope currently for Phase 1 (mainly for use in distributed operations and disaster recovery/business continuity), the hardware and software stack proposed must support replication capabilities and be aware of distributed facilities. In this case, “Replication” should be capable to support full or partial based on policies (i.e. replicate only international content).

1.6. Storage ManagementThis is the software layer that facilitates the management and efficient utilization of the multi-tier storage environment used by the Media CEtre. Storage types will include landing zones for transferred content, WIP for content processing and packaging, bulk storage, etc.

1.7. Search (Internal/External)Facilitate the queries against primarily structured internal Media Centre data/metadata (from the UI or from other Media Centre services) as well as linking for searches of external systems. This should include all component inventory as well as programme metadata.

2. Utility Services

Most of these functions/services deal with logging, event and exception management, and notification during workflow execution. These should produce data that is auditable for events across the system and accessible via search.

2.1. System LoggingSystem Logging helps in monitoring and diagnosis of complex distributed systems. Centralized logging and auditing of services, errors, service orchestration status, and integration with logging from other applications (via integrated messaging) will be an important element of Media Centre. The solution should capable of managing, archiving, reviewing, and auditing of all the logs produced by the system.

2.2. Event Management


Confidential

Event Management centralizes all alerts from various event sources, filter those events based on priority, correlates the alerts with other alerts, de-duplicates and consolidates the repeat events, and provides event enrichment by leveraging other disparate data sources. The solution should be able handle both external & internal events.

2.3. Exception ManagementThe exception management architecture of the solution should have the capability to:

Detect exception Wrap one exception inside another Log and report error information Generate events that can be monitored externally to assist system

operation

2.4. NotificationNotifications provide a mechanism for distributing information about events within or external to the system. Notifications provide a means for communicating between objects. An effective notifications system decouples the message sender from the message receiver as well as the method of notification. With notifications, a broadcast paradigm is implemented in which objects post notifications to a notification center, which then sends messages to objects which have registered their interest in the type of event, or the originating object.

The most common form of notification external to this system will be to send email messages to operators (such as to request action on workflows) or delivery end points (to notify them that a file has been delivered/staged).

2.5. ReportingThe reporting services represent the functionality to support the generation and execution of reports necessary for the operation of Media Centre. The data include, but should not be limited to, information on workflows, assets, utilization, service queues, users and groups. Reporting data stores should be considered so as not to adversely impact performance of the production Media Centre.

3. User Interface

The user interface lists the known user interfaces that are needed to support the functionality referenced in the white papers. The user interfaces listed here represent “portals.” The portal term is used as it is preferable that there be a single UI with different views, features based on user authorization.

3.1. Operations Portal


Confidential

The Admin portal provides operational administrators visibility into all operational data within the Media Centre. This can include, but is not limited to, Inventory, Technical Specs, Workflows, Operational KPIs.

3.2. Vendor PortalThe client/vendor portal provides an interface for clients and/or vendors to interact with the Media Centre. This portal should provide visibility into Workflows and Tasks as well as provide file transfer capabilities to enable vendors to provide or download assets that are required to fulfill Workflows. Vendors can be either internal or external contributors of content.

4. Content ProcessingCollection of services generally characterized by the integration of third party software for the purpose of transforming or otherwise manipulating Components to meet a desired Technical Specification.

It is likely that in Phase 2, or sooner, these Services will be distributed in groups for disaster recovery or performance reasons, perhaps across geographies, so this should be factored into the proposed architecture.

4.1. TranscodeConversion of file format (codec and or wrapper) as well as other file properties (such as bit rate, frame structure, frame size, etc.) from a given set of inputs to outputs.

4.2. Standards ConversionGenerally includes:

Pull down or rate adjustment to convert from HD into SD cadence, color space, etc.

Changing frame rates, resolution, etc. within HD such as from 1080i to 720p

Within SD, PAL to NTSC and vice versa

4.3. WrappingWrapping of Product and or Packages for further processing in common formats such as MXF, ZIP/TAR/Stuff-It, directory structures.

4.4. ChecksumCRC, MD5.

4.5. Technical QCAnalyze files intended for ingest or delivery for integrity and other issues (e.g. bit rate, codec, colorspace, aspect ratio, format compliance).

4.6. Content Formatting


Confidential

Addition/replacement/removal of cards/logos, bars/tones, slates, commercial black (at defined locations), and addition/subtraction of “textless” material to a set location in the programme.

5. Package Assembly ServicesPackage Assembly Services provide the functionality to combine product and supporting materials according to client specifications and prepare for delivery.

5.1. Metadata Transform Services that transform partner supplied metadata to client or partner specific formats.

5.2. Supporting Material AcquisitionServices enable Media Centre to identify and stage package elements required for delivery such as images, trailers, scripts, etc.

5.3. File NamingSpecific file naming conventions are required by clients. These services must allow for dynamic naming of package elements and packages based on business rules defined in the client profile.

6. Delivery Management

Delivery management is needed in order to ensure that requests result in a delivery. They consist of 3rd party products which can be leveraged for managed file transfers as well as custom notifications and confirmation components that will need to be built. Examples of known delivery methods that Media Centre will be required to support include:

6.1. AsperaIntegration of Aspera as a service. However, the install and management if Aspera is not in scope for the Media Centre project. A separate project will be charged with the install and configuration.

6.2. SigniantIntegration of Signiant as a service. However, the install and management if Signiant is not in scope for the Media Centre project. A separate project will be charged with the install and configuration.

6.3. FTP/SFTPDirectly supported via Media Centre.

6.4. Delivery ConfirmationEnsures that what was delivered matches what was sent as well as creating the necessary messages/status updates for the staging and completion of delivery.

7. Services Layer


Confidential

Most of these functions/services deal with performance, security, monitoring, protocol mediation, and delivery of business services. Most of these functions/services are typically managed at the Service Bus level.

7.1. Monitoring, VisibilityThe capability to manage and monitor the SOA application infrastructure and the messages traveling to/from services (i.e. for faults, errors, delivery failures).

7.2. RoutingThe solution should be able to route incoming messages based on information in the message or based on the end-point it is sent to. The routing can be 1:1 or 1:many.

7.3. Translation/Transformation The solution should be able to translate or transform incoming messages before sending to a receiving service. This can include simple formatting as well as data mapping. This is commonly performed to standardize incoming from external systems into a canonical format.

7.4. Protocol MediationBuilt-in mediation capabilities will make it straightforward for the Media Centre to reconcile the incompatible protocols, data/schema formats and interaction patterns of disparate connected resources. Intermediary services such as these allow integration architecture to eliminate dependencies between service consumers and service producers, making it easier to create a loosely-coupled system that can be changed without disruption.

7.5. Message Queuing/Guaranteed DeliveryThe solution must be able to queue messages it receives in order to both buffer them for a downstream service (often to mitigate performance issues) as well as ensure delivery should the target service be non-responsive (i.e. service down, service busy, etc.).

8. Workflow Management

The Workflow Management layer manages the execution/orchestration and monitoring of workflows which can contain automated and manual activities. The Media Centre will execute business process and content processing workflows as outlined in the RFP.

9. Sony Pictures Networks Offices9.1. London – Golden Square

Distributors will generally interact with the Media Center for the delivery of a file(s) for ingestion into the Media Centre.

9.1.1. Remote Ingest


Confidential

Ability for the Media Centre to perform the Ingest of components from assets stored in a remote location (i.e. London office) with the need to move the assets to the Media Centre data centre.

Assets can then be processes, moved from that remote location as well as replicated, either by policy or operator action, to the central Media Centre storage.

This is intended to facilitate remote office workflows and prevent the need for assets to move to the Media Centre and then back out to a remote office where work needs to be performed.

9.1.2. QC/Edit Tools IntegrationAs defined in the original RFP document.

9.1.3. Audio Tools IntegrationAs defined in the original RFP document.

9.1.4. Graphics Tools IntegrationAs defined in the original RFP document.

9.1.5. Promos Tools IntegrationAs defined in the original RFP document.

9.1.6. Localization Tools IntegrationAs defined in the original RFP document.

9.2. Madrid, Budapest OfficesThe offices in Madrid and Budapest will require similar abilities to each other. This is currently a subset of the requirements for the London office, though it should be expected, and the system capable, of expanding to include all functions to this office as required.

9.2.1. Remote IngestSee Above

9.2.2. PromosSee Above

9.2.3. LocalizationSee Above

10. Security and Administration Services and IDM Integration

The principal objectives of the security architecture are as follows:

Complies with the rules set forth in Sony Corporations’ Global Information Security Standards (GISS) and Global Information Security Policies (GISP) for protecting our information assets; Security compliance should extend to industry standards such as ISO27001 in future releases


Confidential

The security architecture should consist of services that can be accessed by all relevant processes. It is required that the system be integrated with Sony Pictures Identity Management (IDM) architecture to facilitate Authentication (defined below). Additionally, the User Administration process needs to be able to accommodate the IDM integration which needs to be articulated in the response.

Authentication – A set of process and procedures that establish with a high degree of confidence the identity of a given individual, service or machine, through credentials (e.g. username and password, certificates).

Authorization – The process of determining, by evaluating applicable access control information, whether an individual, service or machine is allowed to have the specified types of access to a particular resource. Usually, authorization is in the context of authentication. Once a user/service is authenticated, it may be authorized to perform different types of access.

User Administration – The process of adding, updating, and deleting user accounts from applications and directories; user administration may include the subordinate processes associated with supporting regulatory compliance by auditing the system and appliance access that has been assigned to active user accounts.

Auditing – Availability of activity data/logging in the application for the use of auditing access and service/resource usage.

11. Interfacing Systems11.1. GPMS

GPMS provides title master functionality for SPE and contains the programme, and alpha, metadata. The data from GPMS will be used for inventory organization as well as for package metadata (e.g. synopsis, talent, genre) that will be required by the Media Centre especially for VOD delivery. GPMS can provide data to the Media Centre through WebMethods managed publication(s) via web services.

For the Media Centre, it is envisioned that GPMS will provide Programme metadata as well as rights information.

11.2. EAGLEntertainment Assets Global Library ('EAGL') is an in-house custom developed media asset management system used for image, video, and documents. Features include metadata assignment, workflow, security roles and groups, video and image transcodes, secure content links for download via Aspera.

For the Media Centre, EAGL will be a source of images, documents, and other assets necessary for distribution packages such as those defined in the VOD workflows.


Confidential

Additionally, the Media Centre should be able to “publish” or distribute content to EAGL for Ingest and management in that system.

11.3. CineshareCineShare is an in-house custom developed media asset management system. Unlike EAGL, which is more metadata search-based, Cineshare can be likened to a managed FTP content transfer solution, integrated with security, transfer acceleration, storage and having a folder-based presentation to users.

11.4. Harris VisionProgramme Scheduling for the majority of UK managed channels (some channels are still managed in Provys, as noted below) as well as all of the channels managed in Budapest. There are two separate instances of Vision – for the UK and Budapest Channels respectively.

11.5. Harris LandmarkAd Sales system used in the UK and Budapest managed channels. This system DOES NOT require integration into the Media Centre. The necessary programming data related to Ad Sales will come to the Media Centre from Vision (Vision and Landmark are integrated).

11.6. ProvysProgramme Scheduling for a number of UK channels not managed by Harris Vision.

11.7. Harris Broadcast MasterProgramme Scheduling and Ad Sales for Madrid managed channels.

11.8. Farmer’s WifeWork Order and Facilities management toolset used in the UK offices. Integration is NOT required in the scope of this RFP, however, future integration is likely to help coordinate operations staff. As such, references to from bidders on previous experience integrating Farmer’s Wife will be taken into consideration.

11.9. Net GainBusiness Intelligence platform used by Sony Picture Networks for complex data analysis. While direct integration is not required, it is expected that the system can make its data model available for export via an Extract, Transform, Load (ETL) process.

11.10. SAPFinancials system used by Sony Pictures. No integration is required.

12. Third Parties12.1. Distributors

Distributors will generally interact with the Media Center for the delivery of a file(s) for ingestion into the Media Centre.


Confidential

12.2. Post HousesPost Houses will generally interact with the Media Center for the delivery of a file(s) for ingestion into the Media Centre. This could be video and audio captured from tape, dubbed/localized audio, subtitles/captions, etc.

13. Master Data Management (Supporting Data Services)Supporting data services provide the services required to manage the data that Media Centre requires from an operational perspective. The following list of data categories must be managed directly by the Media Centre. Some of these categories need not be the master data stores.

13.1. Programme/Alpha13.2. Distributor Profiles13.3. Schedule Data13.4. Client Master Profiles13.5. Inventory Metadata13.6. Package Metadata

[END insert of detailed statements]


Confidential

6.0 AppendicesAppendices include the following sections: Appendix A Bidder InstructionsAppendix B Resource Load ScheduleAppendix C Master Services AgreementAppendix D Information Security QuestionnaireAppendix E Data Protection & Privacy PolicyAppendix F Risk Management Questionnaire[Appendix G] [Generic] questions to Bidders [If needed]


Confidential

Appendix A

Appendix A includes the following sections: Appendix A-1 Outline for ResponseAppendix A-2 ReferencesAppendix A-3 Pricing Proposal [Fixed fee or Time and Materials]Appendix A-4 Resource Loading Schedule


Confidential

6.2 Appendix A-1 – Outline for Response

The following should be included in Bidder response: a) Understanding of scope and SPE’s desired solution as applicable from information

provided in the RFP package.b) Project plan and timeline including major tasks, milestones, and start and end datesc) Project approach and methodology including description of key activitiesd) Outline and definition of deliverables for all services in scopee) Project team and organization including roles, responsibilities and summary profiles of

key personnel (please delineate any subcontractors)f) SPE resource requirements including roles, responsibilities, skill sets and length of time

involvedg) Assumptionsh) Similar project experiencei) Project fee schedule [Fixed Fee or Time and Materials, T&E, Project Term]j) [Data migration/conversion strategy]k) [Change management approach including the following:]

Communication plan Risk mitigation plan Training plan

l) [Critical success factors]m) Other items as determined by Bidder

6.3

6.4


Confidential

6.5 Appendix A-2 - References

List a minimum of 3 references for whom your company has provided a similar solution as outlined in the scope of this RFP package. To be considered responsive, you are to provide the following information per the attached document:


Confidential

6.6 Appendix A-3 – Pricing Proposal

A full description of all Bidder costs to be paid by SPE must be included with the proposal. This must include all fees and expenses.


Confidential

6.7 Appendix A-4 – Resource Loading Schedule

Please complete the attached Resource Loading Schedule in details and submit as part of your response under Appendix A-4 as a separate attachment.


Confidential

Appendix B – Information Security Questionnaire

Please complete the attached Information Security Questionnaire and submit as part of your response under Appendix B-1 as a separate attachment.


Confidential

Appendix C- Sustainability Questionnaire

As part of its continuing commitment to support the environment, and in conjunction with the Sony American Zone Environmental Policy, SPE desires to procure products and services from companies that consider their environmental impact. Therefore, each Bidder must complete and return the Supplier Sustainability Profile form in Appendix C.


Confidential

Appendix D – Supplier Diversity

As part of SPE’s continuing commitment to support minority, women and Disabled American Veteran owned business entities, Bidders are requested to complete the profile in Appendix D, if your company is a certified minority business entity. Bidder’s submission of a completed Company Minority Supplier Resource Profile or being a certified MWBE/DAV does not guarantee future business, but will assist SPE in the overall evaluation of your proposal.


Confidential

Appendix E – Questions to Bidders [If needed]


sony pictures entertainment sap hcm rfpbusiness... · web views to whether or not it intends to...

Documents