Skip to Content
Author's profile photo Santosh Vijayan

Developer meets User – Part 1

I am a developer and most often I think about the various possibilities to make the applications better for the end-user. And very often, the things I perceive as something which improves the end-user experience are just that – perceptions. I hardly get to meet an end user and I assume that what is good for me is good for the end user as well. This is the story of most of the people in the Developer’s world.

So it was a welcome change when we as developers got a chance to go to a manufacturing industry and look how the applications are actually used and what exactly they require. I will share my experiences here and I am sure most of you will agree with what has been said here.

To start with, something about the company. The company we went to does not have an SAP implementation. They tried to fit in a SAP Application but failed in their attempt (more about this later in the blog). The company manufactures Electric Actuators. Actuators are used on top of valves in pipelines to control their movement.

In this first part of the series, I will explain something about the Production process and the learnings for me. The company receives orders from customers and the orders have the specifications for the Actuator they require. Then the manufacturing and assembling starts for that specific order. It is a “made-to-order” scenario. The specifications might be for each component in Actuator. For example, assume that an actuator has 20 components, the order might have specifications for 20 components.

Each of the 20 components have a certain range of variations. Component A can have values 5,10 and 15. Component B comes in 6 sizes etc. Now the final product – Actuator – can be a assembled using any of these combinations – Component A of value 5 with any of the sizes of Component B etc. Based on the customer requirements, the combinations are selected and the final product assembled.

The following are the challenges –
1. Maintaining the Bill of Material because the number of combinations in which you can get the final Actuator are many.
2. Maintaining the right amount of inventory because the customer order can come in any of the specifications and no Just-in-time inventory management is followed.

What my friends (I am not an expert in Production Planning) found out was that standard R/3 application will not be able to handle this scenario. I found this very interesting but I was not very convinced (we have Configurable Products, variants etc., so something must fit in there). Some of the company’s own people had tried implementing R/3 to suit their requirement and failed. We had a discussion after coming back to office and some people believed that the scenario can be handled with certain customizings to our application while some others still believed that it was not possible.

Learnings for a Developer
1. It is not easy to be a Business Process Expert. In actual scenarios, very rarely do we find a perfect one to one mapping between a business requirement and application feature.
2. Even among Business Process Experts, there might be a difference of opinion about the implementation of a solution.
3. The question of “business process changing to fit the application or the application changing to fit the existing business process” is still valid and tough to answer. However big the application is, there might be something somewhere which was not considered and this question pops up.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Gregor Wolf
      Gregor Wolf
      Hi Santosh,

      I hope that you're not the only one having the chance to see how customers use Developers products. I think it is crucial that Developers gain a real world experience. The described problem of variations matches also the Business Case at Siteco. Hope that a solution will be found.


      Author's profile photo Santosh V
      Santosh V
      Blog Post Author
      Hi Gregor,

      It is true. It is very essential that developers get a feel of the end-user experience. And I am pretty sure that the learnings will be incorporated into future developments.

      Thanks and Regards,

      Author's profile photo Former Member
      Former Member
      Hi Santo,

      Nice thought. It falls under the category - " Nice to have, but not always possible".

      You can consider two scenarios - a developer from a software development company implementing/supporting a project for a XYZ client. Here, the developer might be offshore and the companies can hardly afford to arrange for all developers to get the exposure at the client site, considering the budget for the project. Most cases, only the ones in the requirement gathering / onsite co-ordinator gets a closer look at the user requirements.

      Second scenario can be where the developer is a part of the IT division of the client itself, say like me . I visit the plant managers, purchase managers or whoever is the user and dicuss various SAP related issues, what they are looking for and how to handle them etc. Iam amazed to get this kind of exposure, which I never or very rarely got in my entire experience where I have been working in a software development company.