Home Solutions Technique Applied News Service About Contact
Simply put from A to B Exchange of data is no more than this. How?
Basic starting points The same data which needs to be put in at different places over and over again. Information which is present in one system, but is dependent on information from another. Mobile systems with which your employees collect data on the road, which you like to see tied into your back office. These seem self-evident goals. And they are found in nearly every branch, in organizations small or large. Data that goes from point A to point B:  if this is what it comes down to every time, it has to be possible to find a standard solution that is both generic and dynamic. A flexible solution where the customer remains in control over what exactly goes from A to B and has the freedom to decide the relevant conditions and in which form this should happen. Problems can easily arise when information doesn’t find its way to its proper destination. The cause can be a breakdown in communication, not merging the correct data, or the individual elements which make up the information are not brought together at the right time. In this time of information dependency, it strikes us as odd how few options a customer has to get a grip on data exchange within their own organization. And how dependent people are on the supplier of software that has already been purchased or one is planning to purchase. Of course every supplier gives you the same answer: “Sure, we can connect to anything you like, too.” But at what price? How long does a project take, what is the impact on your employees and how much customization must be thought out and documented, built and tested? Sounds familiar? Despite sometimes extremely different starting points, we kept finding ourselves onto this same, uncomfortable path for our customers. So we decided to act.
Basic project approach In any project were we’ve played some or other part in, we have always encountered specific bottlenecks: Demands: Goals were not made sufficiently concrete to infer what had to be accomplished within a project. What defines satisfaction? But mostly: what doesn’t? Resources : There weren’t enough people made available to carry out all tasks for the project. Or not enough people with the necessary knowledge. Who do you really need? Scheduling: Deadlines were set from higher up. Planning was carried out poorly and/or durations were incorrectly estimated. What do you have to do? What has priority? Risks: Risks that could jeopardize the project were either simply ignored or poorly judged – especially concerning matters that were beyond the control of the project organization. Who takes responsibility? In all our projects we start out by answering these questions. To manage issues which flow from these questions, you must remain concrete and keep eyes on the goals and your feet firmly on the ground.