Is a number generator based on hashing an incremental string considered random? Consider the following system

1 - fixed string as a seed, example "something"

2 - concat an increment number "something-1"

3 - hash it, assume it is "9f2054ea4d2c"

4 - take the first 3 digits to get a number between 0 and 4095 for example

The next number will be taken from the hash of "something-2" and so on
No, the next number in the sequence of the generator in the question cannot be safely considered unpredictable. At least one reason for that: we can infer from the example seed value "something" that the seed is not entropic enough. An adversary knowing the method, the hash, and the first 3 outputs or so could very plausibly enumerate likely seeds from a dictionary of common English words, find one that matches known output, and use that to predict further outputs with fair confidence. Even with less output, the adversary can get a slight advantage compared to a random guess.

The scheme proposed would be computationally indistinguishable from true random under some reasonable but unstated hypothesis:


The counter never cycles or otherwise resets, which is not trivial to ascertain in practice (e.g. when adversaries can cut power at any time).
The computations are performed secretly and correctly; no untold leak of seed or intermediary results, or fault, occurs. This is hard to ascertain in practice (for a start, who knows there's no trojan in that computer? Also, side-channel/fault attacks are a real thing).
The seed is secret, large and random-enough that it can not in practice be found by enumeration using the computational power available to an adversary. It is acknowledged that 128-bit entropy is safe with current technology, and twice that more than safe enough even assuming hypothetical quantum computers usable for cryptanalysis. 128-bit entropy can be obtained with $\lceil128/\log_2(26)\rceil=28$ lowercase letters chosen independently and uniformly at random.
The hash is computationally indistinguishable from a Pseudo Random Function. As far as we know SHA-256 would be good enough in practice, especially with truncation of the output as we have here. SHA-512 would be even safer. Further, the HMAC construction could be used (instead of hashing the hash of a concatenation) to combine seed (used as key) and counter (used as the data input) in a manner giving more assurance against hypothetical attacks on the hash.
Note; standard properties of hash funcions are lesser than being a PRF, and do not even include having near equidistributed output for random input. 
Leading zeroes in the hash are kept (which is not entirely clear in the question's statement), so that integers less than 256 are not underrepresented.