Scribd
Upload
442 views

LeanIX - Poster - Best Practices To Define Data Objects

This document provides best practices for defining data objects. It recommends creating mutually exclusive data objects without redundancies, mapping business capabilities first before defining objects, and ensuring data objects have long-term stability and do not change with organizational structure. The document also suggests involving relevant parties from across the business and relying on existing data models when defining new objects.

Uploaded by

Marco Vinicio Lenci
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
442 views

LeanIX - Poster - Best Practices To Define Data Objects

This document provides best practices for defining data objects. It recommends creating mutually exclusive data objects without redundancies, mapping business capabilities first before defining objects, and ensuring data objects have long-term stability and do not change with organizational structure. The document also suggests involving relevant parties from across the business and relying on existing data models when defining new objects.

Uploaded by

Marco Vinicio Lenci
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

BEST PRACTICES TO DEFINE

Data Objects

BEST PRACTICES
STRATEGIC CUSTOMER PRODUCT & SERVICE PRODUCTION PROCUREMENT HR & LEGAL FINANCE & MARKETING
MANAGEMENT RELATIONSHIPS DEVELOPMENT & LOGISTICS CONTROLLING & SALES Data object modeling is a technique for the
representation of an organization’s data objects,
independent of the organization’s structure,
processes, people, or domains.
Competitor Billing information Delivery estimation Bill of material Demand forecast Applicant Asset Account

Don’t create redundancies


Good data objects do not overlap; they are
Goal Complaint Documentation Infrastructure plan Goods Audit Business plan Channel
mutually exclusive. A good test is to check
whether you can assign Level 2 data objects
without any ambiguity.
Customer
Innovation Market feedback Inventory Logistics order Employee Cash flow Contact
agreement
Rely on business capabilities
It is very easy to find which data objects
exist once you have mapped your business
Customer contact
Mission Material plan Machine Purchase category Employee contract Costs Lead capabilities. This is why we recommend first
information
creating a business capability map.

Customer Employee
Portfolio Product Maintenance plan Returns Currency Message Long-term stability
interaction performance Properly defined data objects are fairly
stable over time, persisting throughout
any organizational changes. Only major
business changes should affect them.
Project Customer order Product design Material plan Purchase order Patent External report Offer

Cross-organizational
Don’t get too specific. Data objects should
Strategy Customer profile Prototype Production design Shipping document Payroll General ledger Opportunity remain the same, independent of any
changes that might happen to the
organizational structure.

Trend Customer risk Requirement Production order Supplier Policy Investment Partner
Use existing data models
Many applications (e.g., SAP) will already
have an existing data object models.
Production steering Familiarize yourself with these when creating
Incident Supplier contract Timetable Invoice Price
plan your own map.

Product and Breadth rather than depth


Storage location Tender Work order Payment
service catalog While more levels can help to get a better
structure, it comes at the cost of increased
complexity. Go for breadth and build your
map with no more than three levels.
Transport status Workforce plan Taxes

Involve relevant parties


Leverage insights from representatives
throughout the business. Those responsible
for different parts of the business are
likely to have the best overviews of data
objects. Consider using surveys to collect
information.

www.leanix.net

You might also like