Pharma IT Blog

Blogging about hot topics related to Pharma and IT. Please use the mail icon to subscribe to new blog posts.
Senior certified Project/Programme Manager and business Manager with focus on leading GxP Projects. IT projects - including expert competences infrastructure, Service Delivery Management, application development, SOA and SAP projects.

Conclusions on SAP ATTP implementation

We have been through a long a demanding project and is currently in hyper care.

I have tried to summarize the key points from the project, I hope they might be able to help if you are planning a similar project.

It’s been more than a year since my last blog post( and it’s time to give you an update on the project which I have had the privilege of leading.

Last time we had just finished the POC for SAP ATTP and had found that the solution did indeed meet the customer’s requirement. So, since then we have been in implementation mode.

We are now live with the solution and have been so for a little over a month.

To summarize our learnings, start with end users early - Serialization requirements take some time to familiarize you with, and the sooner the input from the users the easier it is to implement in the design. A universal truth from all IT projects, also applies to Serialization projects. J

Project phase

The implementation of SAP ATTP is not in itself an overly complex IT project. The serialization requirements, the ones already know, are straight forward, and SAP has ensured that ATTP meets all of them. It even in their license model, so no big surprises on the requirement side.

Solution Design

It’s important to know your SAP ECC implementation. If you are to implement SAP ATTP successfully, you will most likely need to update you RF scanner transactions.

The only reason not to do this is if you are exclusively producing for countries which does not have Serialized & Traced requirements. Even in that case, I would strongly recommend updating you RF scanner transactions to meet these requirements, later.

In my opinion SerializationSerialization requirements must be viewed as a funnel, all markets begin with 2D data matrix, then shortly transition to Serialization, then aggregation and in the end reporting. As you are already implementing SAP ATTP, my recommendation is to ensure that ECC is ready as well.  Otherwise you will need to run another project when your first market requires aggregation.

So, with these considerations out of the way we updated the RF transaction to support, all the existing warehouse processes, for serialized and Traced. That means that whenever we scan a pallet (or shipper box, or even bundle) ECC will check against ATTP if the quantity in ECC is the same as the serials in ATTP.

This will of course result in less flexibility in warehouse and production, as an example they can no longer use, MIGO for changing ware house status. They must use our custom build ones.

However, it also means that we have complete control of our serialised and traced products from Process Order Release until Issue of Goods.

That has reduced the need for reconciliation reports between our L3 system and ECC, as we now have complete control of what is produced and transferred from L3 and what is received in SAP.


Se picture below for the interfaces we developed.


We developed interfaces from ECC to the L3 system for transfer of material master data and process orders. This is not related to serialization as these could just as well by inserted manually, but it eases operation with less risk of manual errors.

We also developed a serial number Request/response system from L3 to ATTP, this is a synchronous interface. We went live with ATTP 1.0 in 2.0 this can be done as asynchronous, which in most cases is the preferable solution.

We of course also have a commissioning interface between L3 and ATTP, for serialised materials it after the production of the batch has been completed. For serialized and traced it’s after each pallet. This is necessary, as we need to start ware house transaction before the production of the full batch is complete.

The final interface we developed was toward our 3PL in Korea, as Korea has requirement for Serialised and traced, this is an interface which sends the full hierarchy of serials to our partner in Korea. This is the most complex interface as it needs to handle multiple interactions, for instance samples, scrap, and returns,

Validation approach

IQ in SAP projects is simple, we checked the transport list in each environment we went through, as we were not changing environment configuration.

OQ, we did a full OQ of all functional requirements, this included all the scanner transactions and the interfaces, on our side. We did not OQ the interface on the 3PL side, but did a parallel OQ for the L3 system. This part was delayed and ended up postponing our PQ. The reason for the delay was the L3 supplier’s development effort to create the interface took longer than anticipated. They had only file exchange interfaces as standard, as we needed a synchronous interface for serial number request response we needed a web service.

After the OQ we conducted a full PQ, we had a production line available and tested a full process flow with, Non-serialized, Serialized, Lot based, serialized & Traced and non-finished goods.

This showed a challenge in setting up master data, as we had numerous production sites, but only 1 L3 site server, we could not test on all the sites materials.

We also had issues with getting LOT based material tested, and ended up descoping this from the PQ, as we currently have a manual solution in place, and the serialization requirements will be effective from November 2017 in the USA.

The PQ was the first time our end users tried the system hands on, this process showed that we needed a lot more training in serialization in general, and SAP ATTP specifically.

It also resulted in some minor changes to the design we had made. As well as changes to local procedures.

I would strongly recommend doing an end to end test with a real-life line if possible. This will reduce the number of issues found afterwards significantly. Especially Master data and Authorizations should be focus areas.

Cut over

We planned with a technical go live 3 weeks before the functional go live. This was an installation of SAP ATTP and implementation of the SAP notes needed in ECC.

This was to give us time to configure ATTP outside a closing window.

In the weekend we went live, we started installation on the 3 site servers Friday evening, and begun SAP installation Saturday afternoon. This was to keep SAP open for as long as possible, and because we needed to run the L3 installation 3 times, for that we needed more time.

We experienced a lot of issues during the cut over, primarily because of master data and authorizations. We saw issues with the materials where we had open process orders, this should normally not be an issue, but if you have the option, I would ensure everything is closed before starting the go live activities.

Hyper care

Since go live, we have had a high double digits number of incidents and about 30% is still open.

The high incidents we have had has been with SAP but not related to Serialization, and with L3 system. We have had incidents where batch data was not transferred from ECC to ATTP for serialized materials. This is an issue with ATTP as far as we can analyze, and we expect a note to fix this.

We have had a lot of issues with Master data, and authorization, and some issues with the interfaces from ECC to L3.

I would strongly recommend having people on site on all production sites when you go live, as working with serialization requires significant knowledge of changed processes. 

Continue reading
1380 Hits
1 Comment

Getting ready for Serialization: Conclusions on Proof of Concept with SAP ATTP

Conclusions on Proof of Concept: SAP ATTP

In the last blog post ( we were describing how to prepare and scale environments for installation of SAP ATTP.

Now we can share the experience from SAP ATTP Proof of Concept.
The Proof of Concept (POC) was initiated to evaluate if SAP ATTP could meet specific Business requirements, and would be a better match than OER/AII. For the impatient reader the proof of Concept was successful and we are now continuing into the execute phase of the project.

Aim of the Proof of Concept was to show support for a full business flow by SAP ATTP:

Manage serial numbers

  • Maintain track of objects and events
  • Ensure integrated warehouse processes

Due to limited time the following area was de-scoped:

  • Integrate with production site solutions
    • De-scoped however we build a simulation tool with the tools supplied in SAP ATTP.
  • Integrate with 3PLs
    • De-scoped in Proof of concept
  • Perform regulatory reporting
    • De-scoped in Proof of concept
      • ATTP POC

Focus was on the integration between ECC and ATTP, and the functionality in ATTP.

First priority was to ensure that we had materials in our sandbox environment we could use for testing. We identified a suitable material for testing purposes and marked it as serialized and traced.

Then we transferred the material to ATTP from ECC, define and assign the serial number formats and ranges.

Following the toolkit for Warehouse integration was tested, by building one scanner transaction that enabled us to receive information from ECC and transfer that event to ATTP – enabling that the serials automatically changed status in ATTP and were marked as Shipped when posted goods was issued in ECC.

We also tested ttThe ESC flow (China) where the serials and master data is imported into ATTP.


ATTP offers a better and more flexible solution for handling serialization requirements than the old AII/OER. By building a basic solution, with competent support, we were able to create a full business flow of serials.  We have seen the integration between ECC and ATTP function in real time.

My next blog post will touch on organization and project approach when implementing SAP ATTP.

Additionally we can add that SAP is working to ensure that ATTP meets the Korean requirements for reporting.

Continue reading
3984 Hits

Getting ready for Serialization – SAP ATT system requirements

The Pharmaceutical industry is being met by regulatory requirements which make it necessary to implement Serialization. These requirements vary from market to market and many different technology vendors claim that they are able to meet these requirements.  Regardless, the Pharma company will be held responsible for storing and updating the serialization data throughout the supply chain and report this to the relevant authorities.

One of the software that can be used to support this process is SAP ATT. SAP ATT is scheduled for release on the 15th of September so official documentation is not yet available. Working with our customers we have been part of a PoC for SAP ATT and is able to share some preliminary insights on the technical configuration of SAP ATT.

Here is what we know in respect to system requirements – information is preliminary so if you need the official information you should wait for the official release from SAP.



To implement ATT there need to be a connection to your ECC system, this is necessary for setting up Material master interface, and WH transaction which will be reflected in ATT.



The recommended basic architecture of SAP Advanced Track & Trace should look like the following.

  • SAP AIF 3.0 with a restricted licence for the SAP Advanced Track & Trace is most likely included in the planned architecture for the SAP Advanced Track & Trace system.
  • For the purpose of running SAP Advanced Track & Trace there is no need for installing the AIF add-on on the ECC system as well.
  • For interfaces PI is not necessary as SAP Advanced Track & Trace plan to deliver OData and SOAP webservices (and RFC calls for internal purposes) which can be consumed by most of the interfaces.


ECC Patch level

If you are using ECC 6, EHP 6 - ECC patch level SP8 or later should be sufficient for the ECC add-on of SAP Advanced Track & Trace. I do not know if earlier versions are being supported.


System Specifications

To our knowledge the system should be created with the following minimum specs:

  • 10.000 SAPS - with 4 CPUs // 24 GB RAM.

We have obviously not been able to test yet, but as a rule of thumb it needs to be on a comparable size with your corresponding ECC environments.


If you have comments or additional information please share.

Continue reading
4678 Hits