Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Hi,

I lead a department of about 100 people in a German institution. We are on
M$ products. From these 100 people
- 80 to 90 use Excel for making beautiful tables, and using minimum amount
of cell formulas. Lets call them C users.
- about ten additionally use Excel for making medium complex charts. Lets
call them B users.
- maximum 5 use Excel to a large extent, including VBA programming and Pivot
tables. Lets call them A users.
- I guess that this structure is just the average structure in any
engineering related enterprise.

- I guess 5 of my staff do like M$ and 95 do not like M$
- I would have the organizational power to introduce OpenOffice or
LibreOffice in my department. About 99 of my staff would support me in
introducing OO or LO. Most likely, they would even like me for that.

Personally, I use OpenOffice since many years at home. I am active (> 1.000
posts) in the support forums, focusing on Macro / API issues. Personally, I
like Openoffice. 

The reason I  have not yet introduced OO:
- I want compatibility across all users. I have quite bad experience with OO
/ M$ compatibility in calc and writer. About 20% of my trials required
manual rework, not always successful
- So A, B, and C users have to use the same office suite, even if only the
few A users really use most offered features
- B and C users would be well served by OO/LO.
- Being personally familiar with calc / UNO and Excel VBA, the required time
to achieve a certain programming goal is on average maybe 5 times higher
with UNO. Several Pivot things cannot be done with calc. A users would not
at all be served well with OO/LO.
- This is half due to the lousy documentation of UNO. Even M$ docs are much
better. The other half is due to the lousy implementation. You can never be
sure that what should work from the documentation actually works. I needed
too much trial and error in OO programming.

The costs of the M$ office suite is equivalent to about 5 working hours per
year for each of my staff. I am sure that my staff would loose much more
working time because of the compatibility and programming issues if I partly
or completely switch to OO/LO. This is why I did not (yet) introduce OO/LO.

So, if you want to win in Corporate Environment
- understand that the A users determine the software requirements. B and C
users have to use the same due to compatibility amongst staff
-  focus on quality, not feature adding
- get the programming better documented and work as documented. I am afraid
this requires rework the code from scratch.

Somewhat frustrated,

ms777

--
View this message in context: 
http://nabble.documentfoundation.org/Adopting-LibreOffice-in-Corporate-Environments-tp3322040p3330983.html
Sent from the Users mailing list archive at Nabble.com.

-- 
For unsubscribe instructions e-mail to: users+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.