Periodo Horizonte Tardío: 1450 – 1540 d.C.

Approaching a system design for a supply network artifact, these two meta- requirements need to be transferred into design principles as underlying conceptual foundations, which guide the subsequent design decisions and the development of the supply network system artifact B-Zone.

To fulfill meta-requirement MR1, ‘networked business objects’ (n-BOs) are proposed as the first design principle (DP1). DP1 defines that all business partners should collaborate on the same shared objects on a shared virtualized platform, and document exchange is prevented by definition, leading to the avoidance of inconsistent versions and cross-referencing of documents. The status of an n-BO evolves during the course of the business process.

Along the quote-to-invoice use case depicted in Figure 10 for example, Figure 11 presents an example where the buying and supplying business partners collaborate on a networked business object instance of type ORDER. According to the specific use case, this could evolve from a quote to an order, to a goods issue/receipt (goods movement) and to an invoice, also incorporating intermediate information like purchase order responses and advanced shipping notifications. This follows an object attributes and methods (including interfaces) evolution of the n-BO as the business relationship becomes more mature.

Figure 11. N-BO Type ORDER in the Quote-to-Invoice Use Case

An overview of the state dependent attributes and methods of an n-BO of type ORDER is presented in Table 8, where successor states own inherited attributes and methods from the predecessor state and instantiate incremental state specific attributes and methods.

n-BO Type ORDER State

Attributes Methods

Quote Customer, Buyer, Freight, Goods Issue Point, Planned Route, Invited Vendors/Suppliers/Service

Providers, Description of Items, Qualities (e.g., Weight, Size, Standards), Prices, Conditions, etc.

Create quote state, print quote, send invitation, update quote, notify business partner, etc.

Order Final Vendors/Suppliers/Service Providers, Delivery Destination, Final Conditions, Locations, Incoterms, etc.

Create order state, print order, update order, etc.

Goods Issue / Receipt

Current Status, Current Location (longitude/latitude), Exceptions, RFID Scan Data, Delivered Quantities, Accepted Quantities, Date/Time Departure, Date/Time Arrival, Retour Flag, etc.

Create items movement state, print state, update goods issue/receipt, status notification, exception notification, RFID data load, etc.

4 Conceptualization 48

Invoice Details, Delivery Date/Time Deviations, Quantity Deviations, Quality Deviations, Payment Terms, Credit Memo Flag, etc.

invoice state, update invoice state, deviations calculation, notification, settlement, credit memo, call payment function, etc.

Table 8. N-BO of Type ORDER State Dependent Attributes and Methods

Mapped to the example of the suppler qualification use case, the n-BO type BUSINESS PARTNER (BP) in a supplier qualification use case naturally goes along an evolving collaboration process, where a supplier data set (an instance of a business partner) is further enriched in terms of attributes and capabilities (methods). The status evolution is illustrated in Figure 12, modelling the end-to-end process, from generic contact, to prospect and candidate and finally to a qualified business partner status. The final business partner is the pre-requisite to conduct further unstructured and structured use cases, like contract collaboration or innovation project collaboration.

Figure 12. N-BO of Type BUSINESS PARTNER in Supplier Qualification Use Case

A list of state dependent attributes and methods of an n-BO of type BUSINESS PARTNER is presented in Table 9, where successor states own inherited attributes and methods from the predecessor state and instantiate additional state-specific attributes and methods.

BUSINESS PARTNER State

Contact Name, Company, Title, Address, e-Mail Address, Network Accounts, etc.

Create contact state, print contact, contact request, update contact, notify contact, message contact, initialize supplier qualification, etc.

Prospect Qualities, Certifications, Generic Product Descriptions, Generic Service Descriptions, etc.

Create prospect state, print prospect, update prospect, etc.

Candidate Service Level, Past Performance, Product and Service Details, etc.

Create candidate state, print candidate, update candidate, etc.

Business Partner Terms and Conditions, Actual Performance, Performance Prediction, Contracts, Service Level Agreements, Statements of Work, etc.

Create business partner state, print business partner state, update business partner state, initialize business

collaboration, initialize quote, initialize order (e.g., contact), etc.

Table 9. N-BO of Type BP State Dependent Attributes and Methods

According to DP1, digital documents (structured business objects like orders and text documents like contract agreements for example) should not be transferred anymore between systems and use case steps. They should be kept in the same platform instead. Networked business partners collaborate on shared data of so called ‘networked business objects’ (n-BOs), which are instances of n-BO types.

To cover a comprehensive set of supply network processes, five n-BO types are necessary:

(1) BUSINESS PARTNER summarizes diverse personas and roles in supply networks, like category manager, buyer and sales manager. These could be natural or non-natural persons, such as organizations, plants, distribution centers, stores or departments. (2) ITEM describes all entities that could be the subject of collaboration in a supply network, like products, articles, material, stock keeping units (SKUs), services and investment goods.

(3) ORDER reflects the legally binding agreement of the business partners in the network. It also incorporates both traditional purchase or sales orders and predecessor or successor states of a classical order, for example quote, delivery, and invoice. The latter design feature is called ‘object evolution’. A specific instance of an ORDER type in supply networks could also be a contract.

4 Conceptualization 50

(4) PROJECT defines activities, combining resources and tasks along common business purpose, time lines and milestones. It also comprises programs that can be defined as a higher level projects, hierarchically linking multiple projects to a common business context.

(5) DOCUMENT stands for all unstructured content, like text documents, spreadsheets, presentations, technical specifications and so on, which the networked users could collaborate on.

DP1 institutionalizes the newly introduced paradigm of ‘networked Business Object Sharing’ (n-BOS) which describes a design concept where networked business partners collaborate on the same shared business objects and common data.

To comply with meta-requirement MR2, ‘social augmentation’ of supply networks as design principle 2 (DP2) is introduced. Following suggestions from Oinas-Kukkonen et al. (2010), it is postulated that the increasing relevance of IT-based social interaction should not only be reflected by offering social media tools in companies or by integrating public social media platforms, but by taking a systematic approach to deeply integrate IT-supported social interaction in a supply network context. The resulting proposal is therefore to socially augment existing structured supply network processes by leveraging IT-based social integration. Consequently, this means that the collaboration experience, the way how business contacts are initialized, qualified, and maintained and how business communication applying Enterprise 2.0 are supported for supply networks, would be comparable to the user experience in public social networks like Twitter, Facebook and LinkedIn. By applying similar interaction patterns, it is believed that business user can quickly adopt the collaboration capabilities that these public sites offer. To holistically cover both structured and unstructured data and processes, it is also necessary to seamlessly embed structured objects and processes into the social augmented interaction environment. The corresponding structured data along the unstructured social interactions should thus be persisted in networked business objects (DP1). There should be no significant difference in the user experience when moving from social collaboration activities like news feeds, messaging, or project room collaboration to interactions based on structured data sets like orders, contracts and invoices.

With this tight bundling of the data/process and the people integration dimensions with one common social interaction layer based on a consistent structured, shared (networked) object layer, it should be possible to achieve a high degree of holistic process coverage in supply networks.

Processing all interaction activities in one environment - unstructured activities like identifying and qualifying new contacts, interacting efficiently with previously connected business partners combined with structured data such as contract proposals, quotes or invoices - will avoid media breaks and help to prevent loss of business context.

The design principles (DPs), the meta-requirements they fulfill and the addressed key challenges in supply networks are summarized in Table 10.

Key

Challenge(s) DP1 Prevent dispersal of data

and processes by introducing networked

Business Objects (n-BO)

MR1. Avoiding the dispersal

of data and processes across multiple systems

a, b, c, d, e

DP2 Enable the social augmentation of supply

networks by deeply integrating IT-supported social interaction

MR2. Holistic support for

structured and unstructured data and processes

a, c, d, e, f

Table 10. Design Principles, Meta Requirements and Key Challenges