Using the SAP ME Sizing Spreadsheet

[stuarta1]

The sizing spreadsheets contained in SAP Note 1406846 are used to estimate the storage requirements of the SAP ME databases. However, unless the spreadsheet is completed correctly, the size of the databases can be seriously underestimated or overestimated: there has been one example of a customer overstating their database by a factor of 1000, and preparing their hardware purchase based on this. It is therefore very important to understand how to use this SAP tool in a proper manner, and ideally, the sizing exercise should be completed with the assistance of a knowledgeable SAP ME Consultant.

In the absence of this, this short guide aims to address the key points to which users of the tool should pay close attention.

Note: this guide has been written specifically for the ME 15.0 sizing spreadsheet, but the same principles apply to all versions, with some obvious differences if HANA is being used in version 15.1 or later.

Sizing - what it does

• Estimates the WIP database size.

The WIP database size should remain relatively static if both Archiving and ODS WIP Aging are implemented. However, some tables will always grow, specifically the ID_USED table. This table holds all the unique IDs that SAP ME has ever generated, to ensure that these IDs never get duplicated even if the underlying objects are later archived.

• Estimates the ODS database size and growth rate.

Unless HANA is being used in version 15.1 or later, the ODS database continues to grow indefinitely. The only application tools within ME that exist to remove data permanently from the ODS are the ODS Aging scripts, but this only affects some of the ODS_ tables. The archived WIP data is also stored in the ODS database in the AR_ tables, and this data set will grow constantly.

• Indicates an overall T-Shirt sizing

The resulting Small, Medium or Large T-Shirt sizing should be used in conjunction with the Initial Hardware sizing document in SAP Note 1406846 to deduce some suitable hardware specifications.

What it does not do

Directly provide any information about CPU speed, number of CPUs or cores, or memory requirements for either the database or application servers. Guidance for server specifications can be obtained from the initial hardware sizing document attached to SAP Note 1406846.

Filling in the figures

There are actually only a very few of the figures in the sizing spreadsheet that will usually make any real difference to the overall database size estimation. The reason most of the other figures are there are for historical reasons – customers can and do use SAP ME in very different ways, and so their data profile can be very different, such that the data representing the largest data set in one customer’s database can be negligible in another customer’s database. For this reason, some more obscure figures are requested. In most cases, it will make no difference if the estimate of such values is very inaccurate, or even omitted.

Information Gathering

Information about the production processes that are to be modelled in SAP ME will need to be collected first. Not knowing the answer to some questions on the sizing spreadsheet may be completely inconsequential, and providing a guesstimate for some values may have zero overall impact.

It is recommended to group similar manufactured products together as much as possible, to simplify the process. For example if one main product is manufactured along with several subassemblies, then consider grouping all the subassemblies together using average values for number of routing steps, number of tracked components, failure rates and so on for each subassembly , but remember to total the product volumes across all subassemblies.

If a manufactured product starts off as a non-serialised lot, and is then serialised into individual units, then this should treated as two different products for the purposes of sizing.

Translate production to a model in SAP ME

To use the spreadsheet successfully, how the production is expected to be modelled in SAP ME needs to be known. Unfortunately, questions about sizing often arise before the business blueprinting phase is even started, so it may be that only an experienced ME consultant can provide the relevant insight into how the production is most likely to be modelled. Usually, it is better to assume the worst case and review the impact this has on the resulting sizing. This can also help the decision about how best to model the production processes, if selecting one solution can lead to an unexpected and unmanageable database size.

In general, try to consolidate all of the production into as few “generic” products so that as few columns of information as possible have to be completed. If full details are available for all products, there is no harm in keeping these separated into columns however, and it can aid debugging.

The important figures

These are the ones that really matter and are typically the ones that will account for by far the largest proportion of the typical SAP ME database size.

1) Number of steps on the production router.

If many different products are made, simply average out the approximate number of steps over all products. Weight this by product volume if necessary. For example if 100 units are manufactured over 10 steps and just 1 unit is manufactured over 5 steps, the overall average is still close enough to 10 for all 101 units totalled together.

2) Number of SFCs processed per day

Pay attention to the comments in this cell (and indeed, all cells). If for example the product is manufactured as a panel in a lot size and is later serialised into individual units, then this should be treated as two distinct products, and two distinct columns in the spreadsheet completed. If it is not known how the production will be modelled with SAP ME, then choose the model that results in the largest data set first and review the impact.

3) Average number of transactions per step

Unless non serialised product lots are manufactured, keep the value of this cell at 3 - there really is no need to make this any higher.

If non-serialised production lots are manufactured, then the number of starts and completes etc per lotsized SFC per routing step will have to be estimated. So, for a large lot size this figure could also be very large number (and therefore much greater than 3). Consider a single lot size of 1000 where 100 pieces of the lot are processed at a time: the estimated number of transactions to expect per SFC would be 3 (the “normal number of transactions”) x 10 (the distinct number of 100 piece sub-lots in the lot of 1000) = 30.

4) How many parametric Data Collections per Day

The value provided in this cell and the one associated with point 5) below can easily account for over 80% of the database volume and/or transaction rate, so pay very close attention to these figures.

Parametric (or measurement) data can be collected per SFC at one or more production steps and this collection instance is related to the product (SFC) volume, so for simplicity consider using a formula in this cell that references the cell containing the SFC volume.

Parametric data can also be collected for a resource, so can be completely independent of product volumes. Such data collection could be based on a simple frequency or time period between collections. It is for this reason that the question in the spreadsheet requests data collections per day and not just per SFC.

5) How many measurements per Data Collection

This figure goes hand in hand with the one detailed above, yet the cells are not kept together in the spreadsheet, which is certainly not logical.

If, for example, there are three test steps with a total of 60 individual measurements across all three tests, then complete the cell referenced above with a formula that is three times the number of SFCs produced, and enter 20 (the average number of measures collected per test instance) in this cell.

When collecting measurement data in SAP ME, consider setting the answer to the question “Parametric data to ODS only” to Yes. There is no point in storing large amounts of parametric data in WIP, only to move this to archive later during the archive process.

6) How many time based resources will be used by each SFC

This figure usually does not have a large impact on the overall sizing, but it is often misunderstood and so is entered incorrectly. Consider a typical product that traverses 20 production steps, with 5 of these steps tracking resource time. Now, if there are 10 similar production lines for example, being modelled and consolidated here on this sheet under the same column, the answer is still 5 (the average number of timebased resources visited by the average SFC), and not 10 x 5 = 50: no single SFC visits 50 resources.

7) How many days' data will be kept in WIP

This will directly influence the fixed WIP database size. This figure should be as small as possible, bearing in mind that near real-time reports can always be obtained from the ODS schema. Remember that this figure represents how long the data is kept in WIP after the time that the units have been completed on their routings. Unless there is an expectation that units will be processed further after being completed, or that the core yield or other production reports are being relied upon for accurate production reporting, this can be a very small number: 7 days is not uncommon.

Getting the figures above correct will more than likely provide a reasonable output. Most of the remainder of the fields can normally be ignored or guessed with little or no impact. Experience is really required to know which of these other values could be significant, but if a value is large then it probably will have some impact. Unfortunately, there is no definition of “large” and it depends on the individual object, and the relative sizing of the other objects.

“Global” cells

Note that cells in rows 43 onwards are “Global” meaning only the first column needs to be filled in – these are not product specific.

Known issues or limitations

If the SFC Lot size is supplied, the sizing assumes that the “Panel” is also checked for the material in material maintenance, resulting in a potentially large estimation of the SFC_LOCATION table size. This estimate may therefore be completely wrong if the lot size is large but it not a panel, meaning this table remains empty. But this is unlikely to have a huge impact on the overall sizing.

System Rule settings are not considered, and some of these can cause very large data growth. For example the Serialization rules allows measurement data to be copied from the unserialised parent SFC to the serialised child SFCs, potentially causing a massive multiplication of such data.

The sizing really is an estimate only. The size of individual tables can vary hugely, depending on the length of the data in its key fields. For example, SFC numbers of 128 characters in length would significantly increase the overall database size, when compared with a more reasonable 10 character length, since the SFC number is contained in a lot of columns across many tables. Index sizes are also dependent on the underlying data lengths, and no account is taken for the addition of custom indexes, which are almost always required on the ODS schema, to support custom reporting.

The “transaction rate per minute” (TPM) figure is based on standard production activities, plus parametric (measurement) data. No account is made for the frequency of execution of anything else at all, like POD plugins, reports, archiving, ODS extracts, SAPMEINT outgoing messages, and so on. The TPM figure is only useful for comparison between different versions of the spreadsheet or other SAP ME systems – it really has no meaning about how the chosen model affects the SAP ME application or database servers, and as such is a worthless figure to quote out of context of this spreadsheet. However, any value calculated to be over 2000 should be referred back to the SAP ME Product Management for further feedback and comment before proceeding.

Interpreting the Result

On the Database Sizing tab, scroll to the top and view the “Days In WIP” figures. This is the estimated (and near fixed) total size of the of WIP database, as long as WIP Archiving and ODS Wip aging are both also implemented. A max and min figure are given as a guide of the expected data size range - this is estimated on a 15% and 5% data fill rate per data row respectively, except for parametric data where these figures have been fixed for increased accuracy (but even this can still vary considerably between implementations).

Scroll down and view the ODS database growth rate. This is given in different time periods just for comparison, again using a max and min value based on possible data fill rate per data row. It makes most sense just to refer to the Yearly figures.

On the Server Sizing Tab, read off the T-Shirt sizing and apply this to the Initial Hardware Sizing document in SAP Note 1406846 to establish some server specifications. The storage capacity figure is just a consolidation of the WIP and ODS storage above, but as WIP remains relatively static and ODS grows, its meaning is of limited value here.

Don’t Forget

• To allow for future product volumes
• To revisit the spreadsheet from time to time as the project progresses
• To use the spreadsheet to assess the impact of using new functionality, such as starting to collect measurement data, or to compare timebased versus discreet component traceability