Sure it can, my team is working on a process automation which involves replacing manual SAP form filling with a some virtual machines doing it 24/7.
Currently some person receives an Excel file and alt+tabs frantically to SAP, taking ~9 minutes to fill its several forms. We'll replace this "process" with a XML file and a bot, which does everything in ~1 minute.
It's easier, cheaper, faster and less riskier than asking SAP to have some type of API or access to its DB.
> It's easier, cheaper, faster and less riskier than asking SAP to have some type of API or access to its DB.
Less riskier? Really? I'd be worried about accidentally ending up making changes on a completely unrelated screen, or accidentally hitting "delete" instead of "modify" or something like that after some ordering somewhere changes. Or perhaps some unescaped data ends up manipulating the GUI instead of being entered in as data (eg. a tab).
At least with an API data is parameterized (cf. bobby tables) and the operations that you are doing are fixed.
The "riskier" part is about DB access. In most environment, the powers that be will not allow you to touch it (correctly), doing INSERTS/DELETES/ETC. So you can pass through the risk management gate a form-filler robot, while if you ask for direct DB access you'll hear a "no".
Anyway, even if you read me associating risk+API, I said "it's less riskier than asking SAP for an API". If your project depends on SAP doing anything, you have a high risk of not happening :p
A lot of it really is just that, though as you get complicated interactions and a mess of "if this, then do this, otherwise first look this up then do that based on what you find", it starts to look a little more like expert-system-style AI, which is fairly involved (how do you capture that knowledge from experts, how do you encode it, how do you check for errors or unexpected situations, how can you update/maintain the process knowledge, etc.?).
Think of a bunch of people using <your favorite app> in a way that makes you cringe. They doing it this way over and over without thinking about the problem they are trying to solve. "It's always been done this way..." You cringe enough and figure out the actual problem they are trying to solve and make it so when you watch them work you cringe just a little bit less. You could be the IT guy for a small business, at a bank or a consultant for a large financial software firm. The idea is basically the same. Rinse and repeat and most of all Enjoy...
</jaded>
9 comments
[ 3.0 ms ] story [ 29.7 ms ] threadCurrently some person receives an Excel file and alt+tabs frantically to SAP, taking ~9 minutes to fill its several forms. We'll replace this "process" with a XML file and a bot, which does everything in ~1 minute.
It's easier, cheaper, faster and less riskier than asking SAP to have some type of API or access to its DB.
Welcome to enterprise IT :)
Less riskier? Really? I'd be worried about accidentally ending up making changes on a completely unrelated screen, or accidentally hitting "delete" instead of "modify" or something like that after some ordering somewhere changes. Or perhaps some unescaped data ends up manipulating the GUI instead of being entered in as data (eg. a tab).
At least with an API data is parameterized (cf. bobby tables) and the operations that you are doing are fixed.
The "riskier" part is about DB access. In most environment, the powers that be will not allow you to touch it (correctly), doing INSERTS/DELETES/ETC. So you can pass through the risk management gate a form-filler robot, while if you ask for direct DB access you'll hear a "no".
Anyway, even if you read me associating risk+API, I said "it's less riskier than asking SAP for an API". If your project depends on SAP doing anything, you have a high risk of not happening :p
For example, here's IBM's heavyweight entry: http://www-01.ibm.com/software/integration/wps/