In the project: new possibilities, avoid time guzzlers
Nothing to be installed in your SAP systems!You can start immediately - in all your SAP systems with an ABAP stack.Also in S/4HANA systems.Get a free trial license and discover the possibilities!
Not only in productive systems, but also in development and test systems, formalism often strikes unscrupulously. Supposedly simple things like the lack of authorizations, the availability of test users, cumbersome procedures for data corrections, system openings, etc. hold up project teams and cost time and nerves. Instead of being able to concentrate on the actual challenges of a project, a lot of effort has to be put into bureaucratic hurdles and formalism. Supposed 5-minute tasks mutate into cumbersome and tedious activities. And suddenly you are behind schedule in your SAP project.
Shorten up! Many things can be done faster than ever before with "Shortcut for SAP systems". So you can concentrate on your actual work again and don't get lost in trivialities. You do not have to change anything in your SAP system. Neither transports nor AddOn's have to be installed.
Have you ever been annoyed by the tedious creation of project members and/or the assignment of the required roles? Or the difficult correction of data on a development or test system?
"So after the system copy, all test users will be gone? And the extended authorizations for the project team too? But the creation of the test users took a whole week, and the compiliation and approval of the authorizations for the project team even longer! Can't we salvage this somehow?"
You can use the SAP functions in the "client copy" environment to copy users and their authorizations to another system. All you need is an available SAP System or client. But: it is always "all or nothing"! It is not possible to keep existing users, since a client copy of the users deletes all users that already exist in the target client. Therefore, you must always make a decision when copying a system or client: either use the users and authorizations from the source client, or save the users and authorizations of the target client beforehand (in an available client, which usually has to be set up again) and import them again after the copy. There is no mixed form in between.
What can you do if you want to use the users / authorizations in your test system after a system copy, but want to keep the users that were previously available in the source system? Just think of test users, project members, system users... Isn't it often a struggle until all required users are set up with the necessary permissions? Should all this have been in vain because of a system copy?
With our product we have closed a real gap in the functional range for user administration. Users - and also their role assignments - can be flexibly and selectively copied back and forth between clients. You can also write the users to a file, "park" them there and - if your target client is available again after a system or client copy - transfer the users back to the system. This saves you the time-consuming task of setting up an empty client to hold the users to be backed up.
This way, you can keep tediously set up test users, project team members and system users, saving a lot of time and avoiding errors and annoyance that would arise if the users were manually set up again.
Even if you always have to create the same base of administrators and/or project members for new systems / clients, they can be created quickly and easily via "Shortcut for SAP systems". Simply copy these users from a client into a file and copy the users from the file into your target clients if required. In this way, the new system or client is available in considerably less time. There is no quicker and simpler way.
No, we can't rebuild the system now. All the work we've done so far would be in vain, and we'd lose another week. My goodness, it's all about three little customizing tables. Can't you just copy them from system x to system y?"
There are certainly possibilities via the transport system ("Transport of copies"), but they are somewhat cumbersome if the source and target systems are not in the same transport group. You can also do this with database tools - provided that you can access the database directly from the SAP System, know the database user and the password, know the correct database commands... Usually there are only a few employees in your company who have these requirements. A few...
With "Shortcut for SAP systems" we make it easier for you. Tables can be downloaded from an SAP system to your computer and uploaded again in another system (or another client). This allows you to transfer entire tables or just specific data records from one system/client to another. Fast, uncomplicated and flexible. Especially during project activities you can save valuable time - and therefore money.
"No, I'm afraid that won't happen any faster. I have to assign passwords to each user individually, and it takes time."
Another gap in the user administration of an SAP system, for which we offer a solution with our product. Do 50 test users have to be provided with an initial password in order to start the test? Or are the passwords of 35 system users to be adjusted after a copy has been made so that the interfaces work again? Unfortunately, in the SAP standard this is only possible for each user individually. It is possible to generate a new initial password for many users in one go, but this is then a generated and individual password. This does not help you either for the test users with the password already published to the team or for the system users with their different passwords.
In "Shortcut for SAP systems" you can assign either an individual password or the same password to any number of users. This allows the test to begin more quickly, the interfaces run again more quickly, and Basis administrators or user administrators can once again devote themselves to more attractive tasks than maintaining the passwords of countless users.
"We still need time to correct the test data."...
"Yes, I know it's only a test system, but we are subject to the usual restrictions. Unfortunately there is no quick way to correct the data."
The options for data correction vary only partially between a production and a test system. If no maintenance transaction was defined for a table, it does not exist in a test system. And you generally do not have the option of correcting many thousands of data records in one go - for example, setting a status field.
With our solution you are fast and flexible when it comes to data correction - whether in a production or test system.
"The result of the test run unfortunately turned out worse than expected. We still have to insert a test run, and for this we need the data from the production system again. This means we have to rebuild the test system from a system copy, and unfortunately this takes a week during which the test system is not available to us."It would certainly be ideal if migration programs could deliver perfect results in the first run and thus eliminate the need for further test runs. Unfortunately, the reality looks different and the data contains errors from the migration runs. The correction of these errors is often done quickly. Wouldn't it be nice if you could then start a new test run immediately? Unfortunately, this usually requires the data as it was before the failed test run. In the test system, however, this data is no longer available in the same form.
Usually the following happens: the test system is rebuilt from a system copy of the production system or from a backup before the test run. This can take up to a week, during which the system is not available. The project team does not have a system during this time and the system administration works under high pressure to make the system available again. Idle time on the one hand and stress on the other.
But does the complete system always has to be rebuilt, because, for example, "only" the material master data is needed in its original state again? If the affected tables are known, they could be saved before the test run and restored for the next test run. This could be done in a few minutes instead of a week...