Getting Started

When building your electronic documents or transport contracts using MMT it's often knowing where to start, so to help we have detailed out the most commonly taken steps below:

Gather Examples

Gather examples of the Document(s) that you are looking to replace. This may be a single document or a collection of documents in a process that can be managed better using data exchange rather than paper based document exchange. We often find that documents repeat data, in some cases this is unecessary. Documenting the fields from the paper version against the data attributes creates a relationship to come back to when asking questions to expert groups during transition.

Build Use Cases from the Examples

Gather your use cases from the process or documents you are looking to replace, as once you have a data set you will want to test these cases will work in the data set or electronic document you are replacing. Make some documentation on the use case and the purpose of the process or document. For example do you have use cases that are classed as dangerous goods, do goods move by different modes of transport and will you have or need to use trade product data?

List the Data Attributes

Outline all the data attributes you need to store, take this opportunity to clean up and if working over a set of documents remove the duplication. You should keep the business language used at this stage to assist with communication with your business stakeholders as there will be questions that need to be answered or decisions made upon.

If you don't have the luxury of an Entity Relationship Diagram or UML model being available, it's a worthwhile exercise here to group the data attributes up if you can at this stage, look for the natural split i.e.

• Information about the type of transport

• Information about the goods being moved

• Information about the type of equipment used to move the goods (i.e. Containers, trailer, pallet)

By doing this ahead of mapping to MMT RDM you will be looking for these data attributes in the class they would naturally belong to.

Begin Mapping to MMT

There are a number of ways to do this, but the goal of this stage is to find the data attributes from your processs or paper document and align them to the class in MMT RDM, lots of these will be very natural and using the business names rather than the tripartite names will be easier.

MMT RDM can currently be viewed on the UN/CEFACT site in a html view, as well as downloaded as (xsd, uml, or xls) from the streamlined standards page.

MMT RDM is available in a consumable format for a number of tools designed for data modelling, typically work is contributed using the GEFEG FX software. Work underway in the RDM 2 API project also makes the RDM's consumable by API design tools in a JSON-LD format, the vocabulary can be imported from UN/CEFACT Vocabulary

Depending upon the tools you choose will decide how you perform your mapping analysis from your data attributes to the MMT RDM, you will be looking to create the map and use the elements from the data model to create your own data model for the document or process you are working on.

Tooling will likely make this task easier and quicker than consuming the Excel version, but it is possible to map against the Excel and your outputs or deliverables will also determine this task.

Practical Advice

When undertaking this process we have found that performing the mapping with a small core group of experts to make the initial mapping works well.

Create a wider working group and frequently present this work to them and relate it to the use cases for their understanding along with open questions is an efficient way of working.

The core group then have control and can work through the obvious mappings and questions at pace and pose more challenging questions to the working group to resolve sticking points or answer use cases in the 'real world' giving a rounded output. This process should be repeated until the mapping is complete.

Providing the UML diagrams or Open API specifications to the expert group as one of your outputs usually speeds up this work and creates common understanding between business and software developers who would need to implement. Decide on these deliverables based on the working group's objectives and experience.

Refer to the semantic terms from controlled vocabulary to ensure common understanding for your working group, otherwise problems can appear when its a misunderstanding of a definition, so ensure these are documented and well understood.

Think about the process used that creates the documents you are modelling, check the timing of the data is available from the source of the information, make sure you are solving the whole problem to are addressing. Consider what success looks like for your process before you start so you know when you are finished on the task.

Consider how to pilot the new electronic document or process, test it using real data to ensure that your use cases are covered and workable in this new structure.

Be prepared to re-evaluate as you need to to ensure that the output matches the requirements.

Look at how others in industry have implemented and learn from their work.

Where possible openly publish your work and allow others to participate or adopt the work you have completed.