我开始在一家非IT公司担任IT部门经理。 我的第一个任务之一就是对IT的现状进行一些估计，这样我们可以计划进行服务监控，改进等。我还有另一个人在这个部门工作。
什么将是一个很好的方法来处理这个任务？
我想遵循ITIL指南，因为它应该是一个最佳实践的集合，但我不想马上纠缠。 所以我打算开始使用OTRS作为基本分类的服务台，然后开始build设。 我也在考虑制作一个服务目录什么的，但是我不确定它有多深入，有多less细节需要logging。 我正在考虑制作一个软件和硬件清单，但不知道现在是否明智。
所以我想听听来自ServerFault社区的一些想法，这肯定会帮助我（以及任何未来的谷歌在这里绊脚石）。
忘记所有的事情 – 你首先有两个关键的问题。
这两个项目也让你对整个事件的状态有一个大概的了解，主要是通过看看人们如何回答。 你可能会直接撞到鼠巢，或者得到一些体面的东西。
其他一切都是次要的 – 主要是因为这两个项目不应超过2-3天的时间来查找和报告。
如果你还没有票务系统，这是第一优先。 这样，你就可以说：“嘿，我们被砸了，我的球员每天平均得到50张门票”，或者你可以说“呃，也许我们不需要聘请其他人一段时间”。
之后，库存是一件好事情。 大量的软件会立刻做硬件和软件清单，所以没有必要分开处理。
另外，我会和我的所有员工见面，问他们认为需要改进的地方，并承诺他们所说的一切都是保密的。 如果有真正的问题，你会从他们那里听到。 人们每天接听电话或pipe理服务人员都会知道存在的每一个程序问题。 你只需要把它从它们中解脱出来。
在build立或重组IT部门时，很难超越Thomas A. Limoncelli，Christina J. Hogan和Strata R. Chalup 的“系统与networkingpipe理实践”中的build议。 他们提供经过testing的优先级和要求，我发现这是非常宝贵的。
我很高兴看到你提到ITIL–不仅因为它是我熟悉的框架，而且因为在框架中工作， 任何框架在这种情况下都很有用。 我相信你不需要我告诉你这个，但是ITIL需要根据业务规模和需求进行定制; 如果您正在从事的是一个小型企业，并且您希望实施ITIL程序，那么也许您不需要正式的变更pipe理和发布pipe理委员会，如果这些会议基本上处于一个人的头脑中的话。 这是一个框架，而不是一个海峡夹克。
我首先确定你的基本知识 – @MDMarra和@TomTom都有一些post，这些post包含了我一定要做的前几件事情。 我还会与企业中的IT关键用户进行一对一的会议，以了解他们认为目前的设置能够很好地满足他们的需求，以及在哪里可以改进。
我将使用与关键用户的会议来开始将服务目录放在一起 – 在我看来，这是一个基于用户视angular构build的活文档，因此他们有一个“支持通过x和y方法访问的电子邮件服务”，而不是“Exchange 2010服务包1与2服务器configuration为…”
除了MDMarra对与IT人员会面的好build议之外，我还会利用这个机会让他们站在你正在工作的任何服务目录上，并用它来讨论如何logging呼叫，并解释如何将帮助台呼叫分成服务请求，事件和问题可以帮助他们。
您应该了解您的IT部门和实施的技术如何满足业务需求。 什么是关键的应用程序和服务？ 如果这些应用程序和服务不可用或不可靠，对业务有什么影响？
本洛克伍德在他的Lisa 201主题演讲中有几个有用的链接 。 推荐阅读。