RFP_Attachment_8_-_Product_Eval_Supplement.xlsx

Read Me RFP Attachment 5 - Product Evaluation Supplement

This workbook:

a. Contains 10 tabs, including this Read Me page

b. Provides Business Rule, Workflow (Collaboration Footprints), Exchange (inbound and outbound) and Reference Data overviews and examples

c. Relates to RFP, Section L, Subfactor 4

All data herein is contrived and for illustrative purposes only.

&F &A

&P of &N

Bus Rule Overview Business Rules:

Overview: The examples provided below represent a small subset of the business rules governing the creation and management of USAF “Part” items. These rules are associated with specific business processes and govern the collection and acceptance of information into the Item Master product.

Technically, these rules govern the edits applied to content collected from both an end user interface (i.e., AR template) and an automated inbound system interface. One ruleset is applied to both data collection entry points, thereby preserving data integrity and ensuring data quality. Every set of valid values for a given attribute is governed by written policy that identifies available choices (often referred to as Reference Data Lookup). Content that fails edits flows to an error handling process.

Business rules may be used to set default values, govern picklist choices, and guide workflow routing (based on valid values), Outside of setting default values, Item Master does not automatically correct content that is in error; in most cases, error resolution is addressed at the source (i.e., fixed by an end user or inbound interfacing system) and resubmitted.

Context: It is worth noting that each ruleset has a set of associated behaviors that govern system responses based on the actions being performed. This mean context matters. For example, here are two actions related to a status code attribute:

• Set the status of a NIIN by selecting from a list of allowable valid values (this action combines a reference code business rule with a status identifier business rule); this could be done as a change action to an existing item

• Search all NIINs for a particular status (attribute lookup using a status identifier attribute); this could be done by anyone at any time with rights to search the Parts catalog Notes: These examples show a few simple, complex and compound examples. To that end, not all business rule patterns and permutations are reflected in the Business Rule Example tab. In practice, business rules will be combined to achieve desired results.

In terms of management practices, Business Rules are cataloged items, placed under Configuration Control. They contain a title, category, and Functional Description, as shown below. They contain additional metadata such as Author, Purpose, Status, Date/Timestamps), and Associations (aka Where Used), which is not shown below.

All data herein is contrived and for illustrative purposes only.

&A

&P of &N

Bus Rule Examples All data herein is contrived and for illustrative purposes only.

Use Case: Change Item Status Inactive NIIN: NIIN Status Code = ‘x’

National Weather Service Item Category: reference code lookup The Activity Code for an National Weather Service item is “AA”

Use Case: Search for National Weather Service Items National Weather Service item: Activity Code = ‘AA’

Primary Buy Item Category: reference code lookup – applied to a concept The RNCC/VC attribute combination for a Secondary Buy is ‘3/2’

&F &A

&P of &N

Workflow Overview Workflow (referred to functionally as Collaboration Footprints)

Overview: The examples below outline general workflow concepts that govern Item Master workload. Workflow falls into general buckets as illustrated by the Collaboration Footprint example; a subset of possible permutations and combinations is presented below:

• Simple Serialization, single or multi-step (1 & 2)

• Simple Parallelism, which could also be multi-step w/ one group review followed by another (3)

• Parallel and Serial Workflows combined (4 & 5)

In terms of management practices, Workflows are cataloged items, placed under Configuration Control. They contain metadata such as title, category, Functional Description, Author, Purpose, Status, Date/Timestamps), and Associations (aka Where Used).

&A

&P of &N

Workflow Examples

Wor

&F &A

&P of &N

Exchange Framework Overview Exchange Framework – Legacy and New:

Overview: The Item Master solution will be responsible for integration to both legacy and modern systems using the exposed APIs provided by the vendor product.

In general, inbound and outbound legacy exchanges are structured record layouts scheduled to run in batch mode at prescribed intervals. Exchange mediums include, but are not limited to: S/FTP, MQ Series, M024B, and HTTPS. Content structures range from traditional 80+ card column layouts to XML-based flat file exchanges.

Integration with more modern systems is expected to include options for structured file exchanges in batch mode (similar to those supporting legacy system integration), as well as real-time API exchanges, which can be stateful or stateless, depending upon the transaction and business function being performed.

The examples contain 3 columnar sample layouts (2 inbound and 1 outbound exhange) and 1 outbound XML XSD.

Notes: In terms of management practices, Exchanges are cataloged items, placed under Configuration Control. They contain a long list of metadata such as title, category, Functional Description, Author, Purpose, Status, Date/Timestamps), as well as technical and operational parameters governing use.

All data herein is contrived and for illustrative purposes only.

&F &A

&P of &N

Exchange Examples

&F &A

&P of &N

XML XSD - Outbound

&F &A

&P of &N

Ref Data Overview Reference Data:

Overview: All Item Master attributes share common metadata such as attribute names, valid values and definitions for attributes and valid values. Typically, this information appears as some form of help content to end users. In practice, reference data setup as valid values behave as picklists. Reference data can also be combined to form business rules that govern the acceptance and approval of attribute content.

All reference data is governed by formal policy documents that explicity define attributes and identify what is and is not allowable in a given situation. Amplifying information explaining the information in context is often added to each formal definition. Such clarifications use more colloquial terms and definitions, as opposed to the more formal, policy-driven descriptions. Item Master requires both kinds of descriptive information.

Like all information, this content is strictly controlled and tightly managed by authorized users, who have permission to add, change and delete this content to meet changing business requirements and needs.

Three sample tables ( 2 simple (7, 6) and one compound (14)) from DoD 4100.39-M have been attached as examples. None of these tables contain the additional colloquial amplifying guidance mentioned above.

Notes: In terms of management practices, Reference Data are cataloged items, placed under Configuration Control. They contain a long list of metadata such as title, category, Functional Description, Author, Purpose, Status, Date/Timestamps), as well as technical and operational parameters governing use.

All data herein is contrived and for illustrative purposes only.

&F &A

&P of &N

Ref Data Examples