Create a DTW Replacement Tool
Answered
Many people complain about DTW for importing. Boyum should take a look at how one could implement a better tool with higher usability when doing the import (we have some ideas on making).
If you think it is a good idea then please leave a comment on what you normally use DTW for across multiple projects because if we are to do it we will have to start with only the most common use-cases.
If someone can also share sample files on what kind of source material you import from it would be even better (just replace real names in such so we are GDPR Compliant).
Finally, how should such a tool be licensed?
-
Thank you for your request.
The development team have now added it to our internal planning-system for evaluation.
[Internal Id: 17900] -
I'm pretty sure you can make something better than the DTW with a few days work
The crappy error handling, the vague and useless error messages...
-
@Sam: The Error messages most come from the DI-API and any tool we would make would be given the same error messages back. So do not expect a revolution in better errors. That being said we could make that part a bit better + if the tool makes it less likely to make mistakes the error rate would go down.
btw: What is the normal things you import (Other than of cause BPs and Items)?
-
Would this be in both Hana and SQL?
-
@Dave: Can't see why not... It is just DI-API and it work the same on both platforms (and using Service Layer is such a tool does not really make sense). But remember this is just an early idea where we wish to get your feedback. Still a chance it might not happen if there is no business case.
-
It's great that you guys are looking at this.Maybe instead of replacing DTW, create a pre-processor for DTW files that would perform the validations to check for things that most frequently cause errors. For example, inconsistent number of delimiters on a row, string to large for the defined field, wrong data type, validation of linked data (i.e. Customer Group Number when importing BPs). Since it would be a separate validation process it would not be able to catch all errors, just the most common ones. It could then give more user-friendly error messages because it won't rely on the DI API.This would be something different - it would read the meta-data from the database and build a list of field types, lengths, etc. Then it would do its own comparison with the data in the import file. At the end it would give the option to let the user run DTW. Question - can the DTW Import Wizard be automated? If so the validation piece could provide the answers to the various DTW Import Wizard pages.A bit of a different idea than an outright DTW replacement. Just focus on improving the area where DTW needs help.
-
Thanks for your thoughts, Dave. I see your point, but I'm of the belief that if we are to do it I want to go the whole way. The work the DTW does is the easy stuff (Calling DI-API) so putting that in is easy... I agree with you is all about the pre-import that could be better but I want to deliver the full experience if we are to do it.
The big challenge is that DTW can import so many different objects and that is why I ask for what you are importing... Example how far percentage-wise is if we have BP, Item + Prices... 80% of all your import of only 20%???
-
For Master Data - I'd vote for major imports such as Bins, BPs, Items, BOMs, Fixed Assets, Resources, GL Accounts, and both their subordinate data (BP addresses, Warehouse Locations) and their supporting data (Bin Sublevels, Shipping Types, GL Account Segment values, UOM Groups). Also I often use the UDF import. I've worked on several projects that use complex Advanced GL Determination Rules, so that import is in the list.
For Transactional Data - many of the marketing documents are often used. It just depends on the customer requirements. Use them to load open sales orders, POs, open AR, open AP, and inventory stock levels during customer go lives.
-
One of our data import issues arises because one of our add ons requires the use of power shell, something with generates even more fear than dtw. I don’t know whether any solution could assist with this.
-
Thank you in advanced.
if there is better tool to do our task soon and easy please provide.
-
DTW is not that bad as a tool for a consultant, but it's not really very end-user friendly. A consultant will eventually get around all the nuisances of DTW. For me a DTW replacement tool should be an end-user tool. We should be able to teach and end-user how to do all their imports for an implementation, and even for continuous use after go-live. The biggest challenges for end users are:
A- The dependencies between related templates (e.g. OCRD-CRD1-OCPR-OCRB)
B- Getting the underlying codes (e.g. code 3 instead of "30 Days Terms)
If the Boyum data transfer tool addresses the above, it would be a winner.
It would also be nice if templates could be saved, and imports could be scheduled.
-
Sorry for bringing up an annoying topic, but if this is ever gonna happen there need to also be a business case. Making a tool like this will be a big investment so I can't see a world where it can be a free download :-/
What do you see as a fair way to price such a tool (say if it is 5x easier to use over DTW). Tried a lot of business cases and I think the most fair is a Netflix model (The rights to use the tool as much as possible for the entire Company on a monthly subscription model). That way you pay for it in the months you wish to use it.
Thought? Comments?
-
Putting on my business hat, this one is kind of tough. DTW is most heavily used during the implementation phase. That said the issue with the Netflix model is that most companies will cancel their subscription when they are past their main requirement for the solution. And if a subscription requires an x-year commitment, then companies evaluating the purchase will probably look at it as similar to the cost of licensed software.
As for 5X easier, I think this would be measured from the standpoint of someone who is not very experienced with DTW. Implementers with a lot of DTW experience already know how to avoid problems, what to check for, etc. So the value to them is lessened.
From the partner's perspective - they hire a new consultant who needs to perform data conversions for customers. They know that only some customers will purchase / subscribe to the DTW replacement, which means that at some point their consultants still need to learn DTW, warts and all. So using the DTW replacement with it's 5X productivity improvement for new consultants, doesn't help them get new consultants up the DTW learning curve.
Bottom line, I'd love to see you guys build a DTW replacement, but I'm having a tough time thinking of a strong business case for it.
-
I think that anything that is more user friendly, particularly on error debugging, would be very welcome. We use it for both data take-on during implementation as well as periodic updates for things like inventory and pricing (I know SAP has direct imports for those, but sometimes DTW is the only choice other than writing something to use the API directly).
-
@Dave: I was thinking pure Nexflix model (For the Partners - Not Customers). So If you have an implementation in December you pay for it in December. No projects in January you turn off the subscription for that month... A new project in March?; you turn it on and the software works again until you turn it off. I do not see a commitment length or yearly pay... But again just brainstorming
But you are saying that there is any price to it It will be a dealbreaker?
-
Hello,
if this new tools also imports documents in draft and it is possible to schedule it then it is interesting
regards -
@Rasmus, Marketing it to partners is interesting, and a better model than end-users for this tool. Maybe bundling the DTW replacement with other benefits if a partner subscribes for a full year instead of monthly as needed. Like reduced cost to access Beas content. Like you, I'm brainstorming here.
I like and agree with Alessandro's suggestions, things like scheduling and the option to import documents as drafts create added value. Jose's suggesting of letting the column for a linked table contain the user-facing code instead of the primary key ('3 vs. 'Net30') creates more value. I did this once with spreadsheets using ODBC to read find the primary key using the user-code in the spreadsheet, and push it into the importable sheet.
I really like the pre-processor model I suggested above. Read out the table's metadata and use that check for column type, length, duplicate keys, etc. This will save a lot of time.
Please sign in to leave a comment.
Comments
17 comments