[an error occurred while processing the directive]
RSS
Логотип
Баннер в шапке 1
Баннер в шапке 2
2012/09/19 18:25:32

Requirements to WMS or as it is correct to issue documentation

Even more often at tendering process at the choice of the supplier of WMS (from engl. Warehouse Management Systema warehouse management system) customers use the document where they describe requirements to functionality. Sometimes this document hereinafter is referred to as the tender documentation, the technical specifications (TS), the paper of terms of reference, requirements to WMS - a system and so on. At the same time, sometimes the author of such document does not consider the fact that in the market a large number of products which differ not only with the platform and architecture, but also approach to process automation is provided.

All this leads to what at a stage of preparation of the tender documentation and drawing of the commercial offer the responsible software provider (software) spends bigger time is essential, and it is forced to put big resources to correspond formally to that request which received from the potential customer. As a result it "does not play into the hands" of any of the parties. What it is worth being guided by preparation of such documentation by that it is really useful to reflect in it and what outputs can be created on the basis of the received answers – about it and the speech in this article will go.

First of all, it is necessary to decide on the budget and requirements of business. These are the first and, sometimes, the main criteria allowing to make primary assessment of offers in the market. After that it is possible to pass to assessment of other indicators: functionality, scalability, reliability, high-speed performance and other characteristics of the software product which are estimated on the basis of requirements to WMS - a system.

If the budget is limited, then it is possible to perform the choice among the most suitable under the created description of the "boxed" systems. If business needs are not covered by a framework of "boxed" solutions", the choice extends at the expense of the customized (adaptable) systems of higher level. Even at this stage it is possible to understand that requirements to the systems of different level cannot be identical.

Extent of customization of adaptable solutions which the customer in the tender documentation, as a rule, tries to adjust is different. However, as practice shows, it is frequent in more detailed analysis of technology of work of a warehouse, many processes can be implemented much with higher quality even when using regular functionality to which afterwards the customer also passes.

"In our reference book – more than 300 thousand materials, from which 20% - active. Many articles are multicomponent, and it causes the necessity to create tasks for a warehouse for their assembly of components, or dismantling – for shipment of some component which is absent in a direct type in a warehouse. Is complicated still by the fact that the composition of some materials, despite the same article, includes absolutely different components. Earlier for these purposes we used functionality of our ERP. At a stage of the choice of WMS, we paid much attention to issues of integration, but as a result the supplier suggested to use functionality of WMS for the solution of the specified tasks, and the integration mechanism was strongly simplified, on the contrary. Work of employees became much simpler, the number of the made mistakes was reduced several times, and work speed significantly increased. It is unlikely we could foresee such course of events at a stage of the choice of a system and an implementation team therefore we can only note that not always that effect which we assume to receive is really the best", - Igor Meshkov, the manager of projects of Makslevel company notes, confirming the fact which that already settled, the stable operation algorithm can receive considerable improvements due to use of standard functionality of WMS.

Certainly, there are cases when individual preference is necessary, for example, for the organization of besstressovy transition from the current technology of work to new, under control of WMS.

"For us the possibility of work of personnel on peak sheets was extremely important point. Preserving of the tool, usual for the employee, really gave the chance to switch to functionality of WMS in very short terms, but need of processing of exclusive situations by means of information booths and controllers did not allow to increase performance more, than by 20%", - the logistics director of Velez Group company Yury Syrtsov comments. - "Approximately within half a year we made transition from peak sheets to radio terminals, and this step allowed us to exclude bottlenecks of our process, having given the chance to increase personnel performance still approximately by 10%. On a new object we started a system using terminals at once, using already acquired best practice", - Yury Syrtsov summarizes.

In this situation, the requirement for support peak sheets is quite logical. But it is important to note: if the customer, for example, expressed in technical requirements to a system the need of work in the "one peak sheet-one delivery note" mode, such option could deprive of it an opportunity to gain similar effect. The matter is that in the specified project the algorithm of scheduling of tasks was significantly changed. If earlier one peak sheet really corresponded to one delivery note, then in implementation using WMS it corresponds to one tovaronositel for whom a system predeterminates the contents taking into account weight and dimensional characteristics, a laying order, and a set of other parameters, including a loading order in the vehicle for reduction of labor costs when unloading in delivery points. Besides, when forming requirements to the supplier, employees of the customer did not assume that such operation algorithm will be used.

For this reason with requirements of WMS it is recommended to exclude that information which can concern architecture of software, or algorithms of implementation of functionality from the document. For example, the formulation "a possibility of adding of unlimited number the analyst for accounting of a remaining balance" belongs not to the specific solution, and the platform more, and reminds search of tools for development more. If such task is not necessary, then it is possible (and it is even necessary) to specify real tasks: "existence of algorithms for work with the food having limited expiration dates, the equipment with serial numbers and also alcoholic products". Experience of the supplier will allow it to estimate the available industry solutions and to offer the most optimal variant of automation. Moreover, at instructions of groups of goods with which work is performed there is an opportunity to obtain within the meetings the additional information from the supplier. For example, the requirement "a possibility of the indication of strategy of reservation and scheduling of tasks at the level of each order line" can turn in a row settings with automatic detection of an optimal operation mode that will allow not only to reduce time for the indication of strategy and algorithms in each order, but also to make assessment in the automatic mode from the level of runs (routes), the available stock and delivery conditions on a residual expiration date.

Sometimes documentation in which screens of interfaces, an order of clicking buttons and also algorithms which should be implemented in a system are described meets. If it is about new product development, then such approach is quite justified, but most often requirements form in relation to already ready system which will hardly conform to the set requirements at least owing to what the product with strongly changed functionality and the user interface will update and support difficult (and it is expensive). Many such "exclusive" products have quite serious restrictions both on opportunities, and on scalability, and there are many precedents when after some usage time of a similar product, the customer switches – besides – to the standard solution with settings under its processes.

Separately It should be noted, as approach to settings in different products can be a miscellaneous too. For example, in some products parametrical transition between cargo handling stages is implemented. It means that if the Control after Acceptance checkbox for, say, any goods is selected, then these goods will go to a control zone. Such approach has the shortcomings. For example, if the authorized user decides to use transition, non-standard for a system, from one process to another, then the address to the supplier will be required, and – as option – implementation of one more parameter.

If we consider application of a system of rules, then it allows to consider each process without tough binding to other processes. For example, such scheme is quite implemented without any programming and completions: "If during acceptance for goods X Y deviation was specified, then it needs to be sent to a control zone".

Or, we will tell: "if on the placed pallet there is one article, but several expiration dates, it should be sent to a partition". For this reason it is so important to pay attention to compliance of a system to required parameters of scaling. What in one system can be configured for an hour in another will be implemented several days.

It is relevant as well a question of the data model applied in a system. In most WMS the fixed model with the predeterminated "communications" and "entities" for which expansion it is necessary or to address the supplier is applied, or to have very uncommon knowledge of programming.

If the technology of work of a warehouse can quickly change, then an opportunity to implement and use own model for specific settings, occasionally, is extremely necessary. For example, when using enough rare and not always obvious attributes in the system of rules ("replenishment of promotional materials with unit dimensions exceeding 0.2 cubic meters on the specific floor site of set", "a stikerovka adaptation labels of all goods shipped to the Ukrainian clients").

Summarizing the aforesaid, it is possible to select several main recommendations for drawing up requirements to suppliers of WMS:

  • it is necessary to make a start from requirements of business and specific objectives;
  • the description of unique interfaces and algorithms increases labor costs of the supplier by implementation and, respectively, cost of such works and also the subsequent support of the solution;
  • important selection term for actively developing companies having the unique or quickly changing algortima is the issue of scaling and simplicity of settings;
  • it is necessary to consider the development strategy of the company: it is quite probable that covering now the minimum requirements 'the boxed solution' very quickly it is necessary to invest in search and implementation of more shirokofunktsionalny system;
  • important source of information on a system is dialog with the working groups of suppliers, reference visits on implemented projects, competent assessment and/or study of technology that can reveal the essential parts requiring the implementation at implementation of WMS and, respectively, fixation in technical specifications.

These recommendations together with the analysis which is carried out, as a rule, standard functionality of WMS - the systems of rather standing business objectives, will allow to make assessment of decisions without excessive labor costs on problem definition on development of new software and potential risk of increase with respect thereto in the cost of the purchased product.