From UG

Current revision as of 15:56, 2 July 2012

[edit] Mantis / Code Branch / Environments

[edit] Statements of Work

SOW1 - Prototype - http://ct.jaguarfreight.com/wiki/POEM:_SOWs

[edit] Purchase Order Event Management Overview

<Executive summary of business justification(s), business objective(s), high level project deliverables, project vision, all stakeholders, etc..>

[edit] Business Objectives

[edit] The need for management information – context

Management information is at the heart of any business that strives for continuous improvement. The principal benefits are that the provision of the right information not simply data:

• Ensures that activity is linked to outcome;
• Effort is focused upon needs of customers;
• The management perspective migrates from providing excuses to delivering results;
• Makes performance a culture of continuous process, instead of occasional ‘snapshots’;
• Promotes communication and collaboration.

[edit] CyberTrax™ Purchase Order Event Management – overview and benefits

For CyberTrax™ customers, POEM is designed as a web-based platform that provides management tools and visibility of Supplier PO Events and milestones, from the PO Issued date, to the creation of an ASN. There are several benefits:

• Elimination of redundant data entry, built in documentation (pallet labels, shipping instructions, Proforma Invoices and Packing Lists), Embedded regulatory compliance tools and exception reporting will improve and streamline the overall processes, and provide centralized visibility and automated event management efficiencies across global inbound supply chain stake holder groups;
• Delivery of performance data and BI will support a continuous cycle of improvement within a company’s planning, purchasing, and transportation (inbound Supply Chain) groups;
• Reliability and predictability of inbound supply chain events and improved regulatory compliance management tools, along with improved expectation management.

CyberTrax™ KPI and BI module Jaguar Freight Services

[edit] CyberTrax™ Purchase Order Event Management – interface

POEM will be designed to provide the same intuitive user experience associated with the Jaguar Freight Services brand, and will be fully integrated with other CyberChain™ solutions (Cybertrax™, ASN Portal™). POEM is a User Interface providing various users with customizable access types (visibility, edit) for the viewing, monitoring, updating and reporting on Supplier Purchase Orders. POEM facilitates a number of functionalities, principally as it relates to managing Purchase Order Events, and provides a centralized, cloud based process, communication and management solution. In line with Cybertrax™, flexibility, customization and scalability underpin POEM’s architecture.

[edit] Project Stakeholders & Roles

• Simon Kaye - CEO - Project Sponsor
• Marc Selter - VP - Product Manager
• Alex Dobrovolsky - Director of Technology - Solutions Architect
• Denise Guastella - CT2 Support Manager
• Kostiantyn Ushakov - CEO/CTO Elcosol
• Perry Lee - CT2 Project Manager
• <TBD> - Elizabeth Arden Engagement/Relationship Manager
• <TBD> - Elizabeth Arden Technical Project Manager

[edit] Project Management Plan

<Scope Management Plan, Integrated Change Control Process, Quality Management Plan, Communications Plan>

[edit] Project Scope

<Identify in-scope and out-of-scope items>

[edit] Project Dependencies

<Identify internal and external dependencies to the project>

Internal Dependencies

• International Portal
• DR/KPI

External Dependencies

• Full participation & commitment by Elizabeth Arden

[edit] High-Level Timelines

<High-level milestone dates>

[edit] Prototype1 Milestones

[edit] Risks

<Identify internal and external risks to the project: schedule, resources, technical, business, cost, market conditions, external vendors/partners, etc..>

• [External Risk] Elizabeth Arden has 5 ERP systems that may not be able to meet all integration specifications.
• [External Risk] Elizabeth Arden Technical Project Managers will dictate timelines. Jaguar Freight Services has no control over EA resources or schedules.
• POEM is the first project to integrate CT2 with Elizabeth Arden ERP systems.

[edit] Assumptions / Constraints

<Identify all assumptions and constraints for this project>

Assumptions

• Critical resources (1 FTE Analyst and 1 FTE Developer) will be fully allocated to this project for its entire duration.
• Elizabeth Arden will provide resources and technical assistance when necessary. Any delays or costs associated with EA resources will not be controlled by Jaguar Freight Services.
• All major requirements would have been identified during the requirements/design phase of this project. Any requirements identified post design-phase will have minimal impact on project schedule and scope.
• All changes will undergo formal change control process.
• All non-working periods (personal vacations, holidays, etc..) will be baked into project plan.
• All resources will have adequate knowledge of business & technology to fulfill their roles & responsibilities with minimal training.

Constraints

[edit] Business Requirements

<List each business requirement under a separate heading. Also include process flows (UML, Sequence Diagrams, Swimlane, Flow chart, etc..) as applicable>

NOTE: ALL GREEN USE-CASES ARE IN SCOPE FOR PROTOTYPE-PROPOSAL (SOW1)

http://ct.jaguarfreight.com/wiki/POEM:_SOWs

[edit] Purchase Order Event Management Context Diagram

[edit] BR1.0 [Manage Purchase Order Life cycle]

The primary objective of Project POEM is to manage the Purchase Order life cycle of Elizabeth Arden Purchase Orders within CyberTrax2. This includes all domestic and international EA Purchase Orders that are managed and transported by Jaguar Freight Services.

The life cycle of a Purchase Order is born within Elizabeth Arden's ERP system. The purchase order is a contract between Elizabeth Arden and it suppliers. Once a Purchase Order is "ready" it is then sent to CyberTrax2 where it will await fulfillment by an EA Supplier and Shipper. If a shipper fulfills a PO, then he/she can create an Advanced Shipment Notification (ASN) and proceed through the normal life cycle of an ASN (with some new variations).

Note that Supplier roles and Shipper roles are independent. They can be filled by different people.

Purchase Order Release Concept

Purchase Orders can have releases associated with them. An open Purchase Order can have multiple releases - each release specifying their own due dates and quantities. Basically a release can be thought of a child to a Purchase Order and should inherit all functionality of a Purchase Order.

[Notes from meeting with Marc 6/28/12]

A client will either utilize releases with all their purchase orders, or they won't. We can treat each PO:Release combination as its own entity. If a client utilizes releases, they should only send us PO:Release combinations, if they send us a PO w/o a release, we should reject that record.

Supporting PO:Release reporting will need to be implemented and designed (pending further clarification & requirements). We can treat Purchase Order:Release as a single entity. When a PO:Release is imported into our system, it will be treated as an actionable order. See below for a very rough draft of a PO data feed.

[edit] BR1.1 [Elizabeth Arden ERP Integration]

Elizabeth Arden employ multiple ERP systems. Purchase orders originate from within Elizabeth Arden ERP systems. These Purchase Orders will need to be imported into CT2. The support for bi-directional updates have yet to be determined by Elizabeth Arden. Imports should be logged so that we can backtrack and troubleshoot interface issues if necessary.

[edit] BR1.2 [Review/Update PO]

Elizabeth Arden Suppliers will need the ability to review all uploaded Purchase Orders. They need to be able to review Purchase Orders and then update dates and other elements as necessary. Read-only/edit permissions should be flexible and controlled on a per-supplier basis.

[edit] BR1.3 [Purchase Order Fulfillment - open, full, partial, or reject]

Shippers need the ability to confirm or reject purchase orders. Shippers will need the ability to fulfill purchase orders. POs will need to be mapped to specific shippers. All updates to POs must be logged.

• Open Purchase Orders - Purchase Orders that are issued in advance and expires after set interval (either date/time or number of executions). Open POs also include ASN Rejected shipments.
• Full Purchase Orders - Purchase Orders that can be fulfilled in FULL. Shipper has all items in stock and can ship the entire purchase order.
• Partial Purchase Orders - Purchase Orders that can only be fulfilled partially. Partial Purchase Orders remain in an OPEN state until it has been fulfilled in its entirety, cancelled, or expired.

[edit] Order Fulfillment Workflow

[edit] BR1.3.1.4 [Create ASN]

Once a Purchase Order is confirmed & fulfilled. The shipper should have the ability to create an ASN. Most of the information in the new ASN should be populated by the PO data. The ASN will then go through a variation of its normal life cycle. Details for automatic approval need to be determined.

[edit] BR1.4 [Upload Purchase Orders]

Planners should have the ability to bulk upload Purchase Orders directly into CyberTrax2. We need to build a module for them to upload their Purchase Order files (*.txt, *.xls, *.csv - filetype to be determined). This should provide similar validation as the ERP integration. This will include a new user interface for them to upload Purchase Order file(s) and will also need an interface to report and log invalid files. The reports should be detailed enough such that they can direct the Planner on how to fix the discrepancies in their file before re-uploading.

We must design the file format and also determine which data elements are required for us to successfully import POs into our system.

[edit] BR2.0 [Communication]

CT2 must be able to send notifications to stakeholders regarding PO updates and events. CT2 should have the ability to send automated notifications as well as ad-hoc communications that are initiated by end-users.

• Automated Notifications
  • Send notification to all stakeholders when:
    • PO messages are rejected by our ERP Interface
    • When elemenets of a PO are updated
    • When PO is fulfilled
    • Other PO Events (TBD)

[edit] BR3.0 [Documentation]

CT2 must be able to generate and store standard PO related documents (regulatory compliance, shipping labels, shipping instruction, etc..). Shipping instructions will be stored in the system as-is. However, shipping labels, regulatory compliance documents must be generated from within CT2.

• Templates and layout to be defined

Sample documents can be found in Mantis: http://ct.jaguarfreight.com/mantis/view.php?id=3574

[edit] BR4.0 [Reporting]

CT2 should allow for exception reporting for certain PO events (Dashboard reports). Must also implement KPIs from PO metrics (cycle times).

• Download to Excel feature

Purchase Order should be reportable on "Where is" and "Main report"

KPI Dashboards:

• On-time: Ship Date
  • Number of shipments that were shipped on time. Purchase Order may specify a ship date (so that shipments are not delivered too early).
• On-time: Due Date
  • Number of shipments that were delivered on time.
• In Full - Partial Shipments
  • Number of Purchase Orders that were fulfilled in FULL.
  • Number of Purchase Orders that were fulfilled in PARTIAL.
• Lead Times (created to approved, approved to ASN, etc..)

[edit] BR5.0 [International Support]

International Suppliers, Shippers, and Planners are in scope for this project. All modes of Transportation will need to be supported.

• Need to sync up I-Portal Project

[edit] BR5.1 [International Currency Support]

POEM will need to support multiple currencies. Currency conversion rules are TBD.

[edit] BR6.0 [SKU Management]

Users will need to be able to manage SKUs/Items within CT2. They need the ability to manually enter in SKU/Items. CT2 must also support SKU updates via an automated process (EDI..?).

• NOTE: Should be able to leverage current SKU2Planner mapping feature and tack on additional requirements SKU to Planner to import SKU information.

[edit] BR7.0 [Quality Assurance Module]

Suppliers frequently send their products out to quality assurance vendors for quality testing. CT2 should be able to support this workflow. Supplier can mark an item as "ready for QA", CT2 will send a notification out to the QA vendor. A quality tester can then log back into CT2 to either pass or fail a specific item.

Item/SKU Data Elements

• Hazardous - YES/NO
  • If an item is Hazardous, additional attributes will need to be associated with the item.

[edit] BR8.0 [POEM Admin]

All POEM related admin activities should be managed within it's own area. Similar to GM Split Admin. However, address book objects (Suppliers, Shippers, Buyers, etc..) should remain in the Address Book admin area.

[edit] BR9.0 [User Admin]

POEM should enable a large amount of flexibility. Users should be assigned access to POEM portal as well as read/write privileges.

[edit] BR10.0 [Client Admin]

We will need to be able to enable POEM at the client level. There are also various data elements that are related to POEM (Regulatory, Suppliers, EDI interfaces) that should be configurable.

[edit] BR11.0 [ShipperSupplier Admin]

We will need the ability to update each Shipper and Supplier's regulatory information and contact information. Most of this information should come from address book, but will leave that design question open.

[edit] Requirements Checklist

<Identify all functional and non-functional requirements. Maintain standard headings. If a specific requirement is not required, note as Not Applicable. Each functional requirement must trace back to a specific business requirement.>

[edit] Technical Design & Solution

[edit] Mock ups

<Include mock-ups of UI changes, report changes, etc..>

Refer to SOWs:

Statement of Work 1 (http://ct.jaguarfreight.com/wiki/POEM:_SOWs)

[edit] Technology Stack & Architecture

<Include changes to existing Technology Stack & Architecture - new libraries, updated library versions, new software/hardware, new interfaces, etc..>

[edit] Technical Diagrams (Flow Chart, Sequence, UML, Systems Architecture, Technical Architecture, Data Architecture, etc..)

<Include architecture diagrams and flow charts>

[edit] Web / Application (New/Modified classes, methods, etc..)

<List new or modified classes and methods>

[edit] Database (DDL changes - new/modified tables, indexes, stored procedures, etc..)

<Summarize database changes>

Data Elements (Refer to Excel document in Mantis)

Mantis: http://ct.jaguarfreight.com/mantis/view.php?id=3574

[edit] Configuration (Config File changes)

<Summarize config changes>

[edit] Logging (Log File changes)

<Summarize Log File changes and locations>

[edit] External Interfaces (EDI Message(s), external vendors)

<Identify any new external interfaces. Include sample request and reply along with field definitions. Include Source/Target server(s)/webservice(s) and functional accounts. If this is a modification of an existing EDI message, include samples of current message(s) and new message(s)>

[edit] Open Questions

[Submitted by Perry (5/23/2012)]

• Determine ALL Elizabeth Arden integration points (P.O. Issued by companies?) Need to figure out where and how many data sources we’ll need to deal with.
• Try to obtain sample Purchase Orders from all EA P.O. Issued by companies..
  • Using sample Purchase Orders, clarify required data elements to support Purchase Order Event Management within CT2. Will EA provide requirements or will JFS provide requirements? Need to verify that their ERP systems have those data elements available.

[Submitted by Perry (5/30/20120)]

• Please confirm definitions for below PO states...
  • Open [A PO that has been imported into CT2 and have yet to be fulfilled in its entirety (either partial fulfillment or recurring PO)]
  • Impending [A PO where Late Ship Date < today + x]
  • Past Due [A PO where Late Ship Date < today + x]
  • Cancelled [If a PO has been cancelled by ERP]
  • In Transit [Once a PO has been fulfilled, ASN created, and shipped]
  • Delivered [Once shipment has been received]

• Who will provide regulatory information?
  • Tax ID
  • Customs ID
  • Regulatory ID
  • Manufacturer ID
    • All Regulatory information will most likely be managed inside Address Book by a Jaguar account/ops manager.

• Need samples of required documents..
  • Shipping Labels
  • Shipping Instructions
  • Pro-forma invoices

• Should we create a new CT for each item in each PO that is imported in our system? We might have to take this approach as the entire system revolved around CT records.
  • Yes
• Will we also support bulk imports of SKUs?
  • Not for Prototype
• If PO is partially fulfilled, will the due dates need to be adjusted?
  • No
• Do we need to provide an interface to create POs as well?
  • Not at the moment
• Should we just add a few new tabs to ASN for Shippers who have PO enabled? Doesn't make sense for a Shipper to enter the POEM portal to review POs, and then enter the ASN portal to view/update ASNs.
  • No. Keep POEM and ASN separate. May merge portals at a future date, but not anytime in the near future.
• Will a single PO ever have multiple Ship To locations? (example, Item 1 ships to Location1, Item 2 ships to Location2, etc..)
  • Not for our purposes. It will be 1 PO to 1 Ship To location for our purposes.
• Should the PO editor display all SKUs in a single PO? Or just a single line item per window? If we create a CT for each SKU in a PO, then the PO List can have multiple line items for a single PO. However, what happens if a user opens a single line item in the PO list? Will it allow the user to update all items in the PO or just that single line item?
  • The PO Editor should open all SKUs for that PO.
• Can a single PO have multiple SKUs with different dates (early ship, late ship, delivery, cargo due, etc..)?
  • For our purposes, no. All dates should be at the PO level.
• Can a single PO be fulfilled by multiple Shippers from different locations? Ie.. PO issued to a Supplier and then Supplier passes PO over to 2 shippers (1 in US, 1 in China)?
  • Yes, but that can be handled at the ASN level. (ability to select Ship From location - which already exists).

• Will customs documentation differ based on MOTs?
  • No. Also note that ISF is only for US-bound Ocean shipments.

• Are the shipping documents created at the CT, PO, ASN, or Group level? Some documents may have to be generated at Group level (customs), while others (packing slips) might be at the PO (full) or CT (partial) level.
  • Must be flexible - ability to multi-select CTs, create documents at the Group or CT level. Pallet/Shipping labels may have to be created via a template. Think of it as a label generator with some pre-populated fields, but shipper will still have to enter in additional temporary information.

• Should Manufacturer IDs be related to the POs or SKUs? If it's linked to only POs, then what if a supplier ships the same product from multiple warehouses/factories?
  • Manufacturer IDs (MIDs) are linked to addresses. If a an address is marked as a Manufacturer, then it will require an MID.

• Release Number Field - need additional clarification.